compute-runtime
compute-runtime copied to clipboard
intel
cl_khr_gl_sharing GLX support
As discussed in #166 , although the extension has been added recently, only EGL context are supported and having GLX support is required for some applications.
I'm interested in this too, because currently there's no way to use Davinci Resolve on Linux, even though EGL support (which took 4 years to develop) is merged. Waiting for any information on this!
We are open to include this feature in the driver. We are not able to devote engineering effort to implementation at this time, but would welcome contributions from the community.
I'd also like to note that we recently added support for cl_khr_external_memory, which should show up in the August release.
So when I had a quick look at this, one the main issue was the API used to implement the sharing with EGL eglExportDMABUFImageMESA has no real equivalent in GLX.
But when trying to work my way through #667 and talking with some mesa devs, they pointed out it shouldn't be using eglExportDMABUFImageMESA in the first place but instead use MesaGLInteropEGLExportObject, so I've been looking into making the switch.
Now obviously this is still EGL specific, but it has a direct GLX equivalent MesaGLInteropGLXExportObject at least.
FWIW in the branch I pushed in #667 , I have now added GLX support as well.
So the good new is that Resolve starts and you see something in the viewers now : https://i.imgur.com/qyfOARh.png The bad news is that it only does that when running in valgrind ... which like the name suggests, brings it to a grind :sweat:
Found a workaround ... I had to remove the RTLD_DEEPBIND option used in intel-compute to load OsLibraries and then it starts. I'm not entirely sure what the issue is or what the consequences are of removing this, so still some check needed.
But now I can start resolve and see stuff in the viewers. It's a bit glitchy and I get some weird errors :
0x7f72886e4680 | IO | ERROR | 2023-08-10 23:23:50,585 | Failed to decode clip </tmp/osmodevcall-20210326-fixeria-osmoran-status-update_vp9.webm>, track 0, frame 27687: Requested position is outside of track bound.
0x7f72896e6680 | IO | ERROR | 2023-08-10 23:23:50,595 | Failed to decode clip </tmp/osmodevcall-20210326-fixeria-osmoran-status-update_vp9.webm>, track 0, frame 27805: Requested position is outside of track bound.
0x7f72886e4680 | IO | ERROR | 2023-08-10 23:23:50,618 | Failed to decode clip </tmp/osmodevcall-20210326-fixeria-osmoran-status-update_vp9.webm>, track 0, frame 27914: Failed to read the video frame from disk.
0x7f72886e4680 | IO | ERROR | 2023-08-10 23:23:50,655 | Failed to decode clip </tmp/osmodevcall-20210326-fixeria-osmoran-status-update_vp9.webm>, track 0, frame 28032: Failed to read the video frame from disk.
0x7f7288ee5680 | IO | ERROR | 2023-08-10 23:23:53,658 | Failed to decode clip </tmp/osmodevcall-20210326-fixeria-osmoran-status-update_vp9.webm>, track 0, frame 28149: Failed to read the video frame from disk.
But heh, progress !
Interestingly the BRAW standalone player works fine and also use CL/GL sharing (I can see the API calls). ...
(just wanted to say thank you! - awesome to see someone trying to get Resolve working!)
/me is on Nix; might be interesting trying to figure out how to test this :D
So you need to build :
- https://gitlab.freedesktop.org/246tnt/mesa/-/tree/clgl-export?ref_type=heads
- https://github.com/smunaut/compute-runtime/tree/clgl
(make sure to checkout the correct branch as pointed in those links)
You can install in a temporary prefix like /tmp/test_root or something. And then :
export OCL_ICD_VENDORS=/tmp/_root/etc/OpenCL/vendors/
export LD_LIBRARY_PATH=/tmp/_root/lib64
export NEOReadDebugKeys=1
export DisableDeepBind=1
- Make sure the .icd gets installed in that subdirectory, IIRC I had to do something more than set the prefix for that but don't remember. You can also create that file by hand, it's just a text file pointing to the right .so
- Beware of
libvslib64depends on your distro I think.
Then just try to start resolve.
btw, I'm on the unofficial blackmagic discord and on the freedesktop one, so you can ping me there username 246tnt which might be easier than github issues. Also on IRC as tnt on libera.
@smunaut I will dm you as olk on libera once I have time to test it. thanks for your work
For anyone following, here's a preview of the current state : https://youtu.be/-PW1J2Y42x0
That video actually shows a bug in the color parade, I know what the bug is and already have a workaround, just talking right now with the mesa guys to see what the best fix would be.
hey @smunaut, can you backport https://github.com/intel/compute-runtime/commit/8b09bb855e2503e033f684da9b1fcd08802c2156 and https://github.com/intel/compute-runtime/commit/894bab05efb447d249c9f0afdbf0ca62c82395c6? I can't compile your fork with gcc13 without them
Ah will do. But gimme some time, I haven't actually pushed the latest stuff :sweat_smile:
I'll do that tonight.
Ok pushed.
You need the 23.2-resolve branch from my MESA tree : https://gitlab.freedesktop.org/246tnt/mesa/-/tree/23.2-resolve?ref_type=heads
And the clgl branch of this tree (compute-runtime).
I tested it on Fedora 38 and I can say that it works perfectly.
https://www.codelinsoft.it/sito/images/2023/davinci_resolve.png
Unfortunately, the preview video in Davinci Resolve is not rendering correctly for me.
Screenshot (this is supposed to show a flat gradient from black to white):
That said, it doesn't crash or anything, and when I export my Davinci Resolve project, it is all correct again.
I'm using a fully updated Arch Linux with an Intel Arc 750. I manually compiled mesa (source: https://gitlab.freedesktop.org/246tnt/mesa/-/tree/23.2-resolve?ref_type=heads) and intel-compute-runtime (source: https://github.com/smunaut/compute-runtime/tree/clgl-23.30.26918.9).
How can I help to fix this?
Do you use IRC or discord ? Would be easier to do this in a "live" session :)
We can probably create a thread in #resolve on the BMD discord : https://discord.com/invite/blackmagic-design-community-479297254528647188
So just to update the issue here. There were 2 bugs identified :
- One in Mesa itself where it export the texture reporting it as being linear while it is in fact tiled ... The export code doesn't handle GFX12.5+ (Alchemist) cards properly since they have a new tiling mode ...
- One in the new code where the tiling mode is not supported and I'm not sure how to set it.
Note however that theses are not regression, it doesn't work any better in the current cl_khr_gl_sharing support that's currently merged in, so theses patches are still an improvement.
@JablonskiMateusz @eero-t Maybe one of you knows : How can I specify which tiling mode to use ? I know which one is used by mesa, but now I need to tell the compute stack about it ... I found a linearStorage flag but that's a bit restrictive, I need to specify some specific mode ... (and then there is a aux stuff but ... one thing at a time)
Any update? How do I install the patch for OpenCL libraries?
My DaVinci Resolve does not playback at all.
There is an open PR I need to address a couple comments on it and update it to latest code, but I'm a bit busy with life stuff ATM so might take a few weeks until I get to it.
@JablonskiMateusz @eero-t Maybe one of you knows : How can I specify which tiling mode to use ? I know which one is used by mesa, but now I need to tell the compute stack about it ... I found a
linearStorageflag but that's a bit restrictive, I need to specify some specific mode ... (and then there is a aux stuff but ... one thing at a time)
Sorry, unfortunately I don't know either (I'm not driver developer / related to this project, just an occasional bug commenter).
