Resolve on Linux with Intel iGPU

Hi,

So before I get screamed at :
* Yes, I know this is not a supported configuration
* Yes, I know that the linux drivers are missing the required CL/GL interop for it to have a hope of working.

Now that this is out of the way : I have been working on fixing that second point.
I have an experimental branch of both the MESA GL drivers and the intel-compute stack that improve the support for the CL/GL interop under linux, fixing bugs, removing texture format limitations and adding support for it under GLX contexts.

It got to the point where I can finally launch resolve and it shows video in the viewer port https://i.imgur.com/qyfOARh.png and also I don't get any errors in the logs about not being able to create the CL context or not being able to share textures or stuff like that.

Unfortunately I only was able to get that far by running resolve in valgrind which makes it unusably slow. Without it, it crashes early on with what I believe is some memory corruption somewhere (even before CL really get initialized / used).

Valgrind does report a lot of "Conditional jump or move depends on uninitialised value" so those probably should be fixed in resolve but of course there is no way I can check those out myself to see what they stem from.

So my hope is that a Blackmagic engineer can take a look and help me figure out what/where things are going wrong.

Please get in touch if that's in the realm of possibility.

Cheers,

Sylvain

One bug I can already point out to the developers :

During the OpenCL enumeration, `ClGetPlatformInfo` is called with `CL_DEVICE_VENDOR` argument which is obviously wrong, that param name is for devices, not platforms.
It's not the source of the issue, but still probably worth fixing in the codebase.

Not really sure if this is interesting anyone at all but I figured out the issue (although no "proper fix" for it yet :/)

* Resolve uses tbb malloc replacement library.

* The intel opencl driver uses RTLD_DEEPBIND to load some modules, which is required because different part of the graphics stack can have different LLVM version linked for instance and DEEPBIND make sure that each module ends up linked with its own dependencies.

Unfortunately a side effect of the deep binding is that the malloc/free that happen inside those deep binded modules end up hitting the normal libc malloc/free instead of the replacement dynamically loaded by tbb malloc.

So you end up with some part using one set of malloc/free and some other part using another set of malloc/free ... and when one part passes a pointer to another part and that other part tries to free it with the wrong "free" ... things explode.

Not really sure if this is interesting anyone at all

FYI, while I have next to nothing to contribute to this thread, I'm following it and hope there will eventually be some progress.

Years ago, Intel got involved with improving support for Resolve 12.5 on Windows and given their new push for GPU:s maybe they would be interested in doing the same on Linux.

DaVinci Resolve 12.5 Meets Intel® Iris™ Graphics

DaVinci Meets Iris Gfx - Extended Cut

The guy in the video is Mahesh Madhav, an Intel silicon architect.

Thanks, yeah, I would thing improving Intel GPU support now that they have dedicated cards that are more capable (and use the same compute stack and driver than the iGPU). I'd also like to be just some quick cutting / review "on the go" on my laptop, even if I do all the heavy stuff on my workstation.

I made some progress but I'm a bit stuck ATM with Fusion complaining GL_ARB_texture_border_clamp couln't be loaded ... even though that extension is fully supported and I see the API call returning it as supported so I'm not sure exactly what fails :/

So I have Resolve started and running using two different compute stacks :

- RustiCL (which is a generic mesa opencl stack that works with any mesa driver)
- Intel Compute (which is the Intel specific stack written by intel themselves and that has a common "core" codebase used on windows/linux).

When running with the former, it all works fine and I don't notice anything weird.
However when using the second, I get stuff like this :

"Failed to decode clip </home/tnt/Videos/osmodevcall-20210326-fixeria-osmoran-status-update_vp9.webm>, track 0, frame 59829: Failed to read the video frame from disk."

Not all the time, just from time to time depending on where I scrub, and I then get the dreaded Red "Media Offline" error frame.

Now, it doesn't make much sense to me since the same project works fine using the other driver. But in both case I also don't see any OpenCL related failures, everything looks fine when tracing the OpenCL driver, no errors or warnings there.

Also the "Failed to read the video frame from disk" ? I mean OpenCL got nothing to do with the disk. And VP9 decoding isn't even GPU accelerated so I don't see why this would even affect this clip.

Of course the reason I'd want to use the intel stack and not the rusticl one is performance, else I wouldn't bother and just use the one that seems to work fine.

Unfortunately without a bit of help from BlackMagic to guide me as to what this error could mean and what kind of OpenCL misbehaviour could lead to it, I'm not sure I stand a chance of debugging this.
There are no clear things failing and also that message isn't even printed where the error actually occurs but several layer of abstraction away making it hard to pinpoint at what point things go bad.

Call me confused but you're having problems with an Intel iGPU but your signature says you're using an AMD processor?

Yes, I have a workstation that has a AMD 5800X3D and a RTX 4070 and I run Resolve Studio just fine on that setup, no problem whatsoever.

I also have a laptop with a Intel i7-1260P with iGPU where I'd like to run resolve on as well.
Not so much for any "heavy" work (like, no render, not trying to do complex fusion or color work or anything), but just being able to open a project and do a bit of (pre-)cutting or such and things like that.

I found my issue causing the "Media Offline" error \o/.

(`close` was being called twice on the same fd when releasing a texture and on the second one, if the fd happened to be reuse to read from file, it would close that file and cause the read error ...)

You can see the current state of it running at :

There is one known issue remaining : Non power of 2 texture sizes are not working properly.
You can't see that issue much on that video because for 1920px wide project, it rounds up to 2048px internally, but you can see it looking at the parade scope in the color tab, it's "banding". It shows up in the main window too depending on the project timeline resolution.

Given that issue happens identically both using intel compute stack and the mesa rusticl stack, I suspect some difference in the way the memory zones are organized for compute / display on intel GPU ... will need some investigation.

EDIT: Actually found a "workaround" for that last issue ... still need a proper fix, but for the time being it makes it work

That is really encouraging but what is the secret sauce to get media to play?