17.0B Build7 Linux crashes on import, 16.2.7 works flawless

Advance notice: I know my OS is not supported but I report it anyway because DR 16.2.7 Studio works absolutely flawless on it and I have seen similar crash reports in the "Painless install on Linux Centos 7" thread. In addition I work as a Linux admin, but for DR 16.2.7 install no special knowledge was needed.

Installation procedure:
- remove /opt/resolve (DR 16 installation)
- remove ~/.local/share/DaVinciResolve
- run command: sudo ./DaVinci_Resolve_Studio_17.0b1_Linux.run

When running /opt/resolve/bin/resolve DR starts up normally, but as soon as I import a media file (Sony FS7 XAVC-I mxf) it crashes very soon. This is 100% reproducable.

In comparison DR 16.2.7 runs without any issue on the same system. Playback, all the fancy transitions, NR, blur, NeatVideo v5 OFX plugin, mini panel and renders all work without a hitch.

System specs:
Intel 3770K CPU
16 GB RAM
AMD Radeon VII 16GB VRAM
BMD Decklink HD Extreme 3
BMD Resolve Mini panel
OS: OpenSuse 15.2 (identical to Suse SLE 15.2)

amdgpu drivers: amdgpu-pro-20.40-1147287-sle-15.2.tar.xz
Installed with command: ./amdgpu-install --pro
Later I also installed rocm 3..9.0 but that made no difference.
See attached file amd_packages.txt for a list of installed AMD packages.

Log files are attached.

I have the exact same issue. Starts fine. I can import a piece of media and it is fine even shows the contents of the file in the little icon in the media pool, but as soon as I click on it to see it in the viewer or drag it to the time line, down it goes. 16 has been rock solid for ages.

My graphics card is an RX-580. I have tested opening BRAW and some h.264.

What I believe are the relevant lines from the logs are

[0x7f4e0949a700] | DVIP | ERROR | 2020-11-16 16:20:08,389 | Failed to register OpenGL object for OpenCL interop: CL_INVALID_CONTEXT.
[0x7f4e0949a700] | UI.GLTexPool | ERROR | 2020-11-16 16:20:08,389 | Failed to register OpenGL texture to compute API.

I tried beta2. Same thing.

Still an issue in beta 3.

Did you fix this? I am seeing the same thing on Beta 4, both with CUDA and OpenCL.

Edit: I was able to easily downgrade to 16.2.7 which works fine. Luckily I am just starting a new project as my old database got upgraded and so I cannot access my old projects with 16. Hopefully DaVinici fixes this in 17 soonish.

My guess from googling is that 17 beta has a OpenGL context interop error:
- opengl context must be created first
- opencl / CUDA context is created from the opengl context

I guess commands are being batched in some way and Resolve has a bug in the order of operations and the opencl/CUDA context is being accessed before the opengl context is created. I´m on nvidia P1000 so it looks like it´s both AMD/NVidia.

I still have the issue with beta 4 with my AMD card. Next time I log in I am going to try an strace and see if that gives me any new info.

I'm also affected by that issue on DaVinci Resolve Studio version.

Same here.

I installed beta 4 today and I still have the same issue but I have more info to go with it. I was looking at the logs as I tried to drag a piece of media from the media pool down to the time line and I saw this in the logs as it crashed.

Code: Select all

Resolve communication is open and waiting..
Accepted new client
FusionScript Server [7523] Started
Host 'Fusion' [7249] Added
Discard all samples (playback) or generate zero samples (capture)
PulseAudio Sound Server
Default ALSA Output (currently PulseAudio Sound Server)
HDA ATI HDMI, HDMI 0HDMI Audio Output
HDA ATI HDMI, HDMI 1HDMI Audio Output
HDA ATI HDMI, HDMI 2HDMI Audio Output
HDA ATI HDMI, HDMI 3HDMI Audio Output
HDA ATI HDMI, HDMI 4HDMI Audio Output
HDA ATI HDMI, HDMI 5HDMI Audio Output
HD-Audio Generic, ALC1220 AnalogDefault Audio Device
HD-Audio Generic, ALC1220 AnalogFront output / input
HD-Audio Generic, ALC1220 Analog2.1 Surround output to Front and Subwoofer speakers
HD-Audio Generic, ALC1220 Analog4.0 Surround output to Front and Rear speakers
HD-Audio Generic, ALC1220 Analog4.1 Surround output to Front, Rear and Subwoofer speakers
HD-Audio Generic, ALC1220 Analog5.0 Surround output to Front, Center and Rear speakers
HD-Audio Generic, ALC1220 Analog5.1 Surround output to Front, Center, Rear and Subwoofer speakers
HD-Audio Generic, ALC1220 Analog7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
HD-Audio Generic, ALC1220 DigitalIEC958 (S/PDIF) Digital Audio Output
Discard all samples (playback) or generate zero samples (capture)
PulseAudio Sound Server
Default ALSA Output (currently PulseAudio Sound Server)
HDA ATI HDMI, HDMI 0HDMI Audio Output
HDA ATI HDMI, HDMI 1HDMI Audio Output
HDA ATI HDMI, HDMI 2HDMI Audio Output
HDA ATI HDMI, HDMI 3HDMI Audio Output
HDA ATI HDMI, HDMI 4HDMI Audio Output
HDA ATI HDMI, HDMI 5HDMI Audio Output
HD-Audio Generic, ALC1220 AnalogDefault Audio Device
HD-Audio Generic, ALC1220 AnalogFront output / input
HD-Audio Generic, ALC1220 Analog2.1 Surround output to Front and Subwoofer speakers
HD-Audio Generic, ALC1220 Analog4.0 Surround output to Front and Rear speakers
HD-Audio Generic, ALC1220 Analog4.1 Surround output to Front, Rear and Subwoofer speakers
HD-Audio Generic, ALC1220 Analog5.0 Surround output to Front, Center and Rear speakers
HD-Audio Generic, ALC1220 Analog5.1 Surround output to Front, Center, Rear and Subwoofer speakers
HD-Audio Generic, ALC1220 Analog7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
HD-Audio Generic, ALC1220 DigitalIEC958 (S/PDIF) Digital Audio Output
Host 'Fusion' Killed
FusionScript Server [7523] Terminated
Socket disconnected
Socket disconnected

That got me curious about fusion. So I restarted, imported a JPG to the media pool from the edit tab. Then I switched to the fusion tab and dragged the JPG from the media pool into fusion and it showed up in the viewer. This is the first time I have been able to actually view any media in 17. Unfortunately as soon as I clicked on the edit tab it crashed again.

I retried the same process with Braw file and I was able to play it in the fusion tab. But again as soon as I click the edit tab down it goes. Is any one else with the same issue able to do the same thing?

I also tried restarting importing a BRaw file in the edit tab and then right clicked and generated optimized media. That worked fine but again when I drag it down to the time line it crashes.

...

I will try again tomorrow evening to see if I can reproduce and collect more information. Would you mind sharing some link to some BRAW media, please ?

Seems like the same issue I have, 16.2.7 Free and Studio run great. 17B4 can't open any content without it crashing. New Project doesn't even open WAV files. Hopefully there's a solution soon.

I just tried beta 5 and it is still the same. I do have more info though. It doesn't actually seem to be an issue with media per say. If you open the edit page and don't import any thing just create a new time line. Then double click on or try to drag the time line it will crash. That is with no media. If I open DR and then click on the media tab it crashes immediately.

Still borked with beta 6.

Exact same issue here.

Ubuntu 20.04 here. RX 570 8GB. From all betas. 1-6 currently. All crash upon trying to view something in the viewer. I have found the same thing you have with fusion. I can even import full videos into fusion with audio. They playback and work fine. But every other tab crashes instantly when I try to run anything into the viewer. This is applied to if I add a solid color clip or text. So its clearly something visual

My AmdGpu-Pro drivers were installed with ./amdgpu-pro-install --opencl =legacy

Tried beta 6 yesterday. Same issue. This is really painful, im dying to using the new gamut and magic mask.

I will let you all know If I find anything

I too have this issue. DR16 works fine, but DB17.x crashed when trying to display video (shows first frame and crashes).

Ubuntu 20.04.1 LTS (clean install)
GPU: RX580
GPU driver: AMDGPU-Pro with OpenCL all proprietary drivers from AMD website.
CPU: AMD Ryzen 7 2700X
RAM: 32GB

Installed with no issues via "makeresolvedeb_1.4.3_multi.sh" install script.

Ditto, running Manjaro, AMD PRO workaround, with CURL 73 downgrade.

If I wait a few minutes without doing anything, thumbnails for JPGs load in the Media Tab. The moment I select a folder with videos in doesn't matter what format or click edit / cut tab - crashes.

Again though V16.2.8 works no issues. So want to use my Speed Editor.

I even did a CLEAN install of D17B6 on Windows 10, latest drivers. Even with 1080p content it's just a stuttery mess.Try playing at 2x+ etc is crazy and simple transitions stutter. Seems we can only use Davinci 17 on MacOS with any semblance of performance or stability. ;(.

I understand it's BETA but hard to test on Linux when we can't do basic editing.

Still the same problems with build 7. The truth is if they are up to build 7 and they haven't even started looking at an issue this big this wasn't a beta it was an alpha rushed out to meet the M1 launch date.

I am also having the same problem.
DRs 17 is literally unusable at the moment. It is crashing during following cases for me:

• Pressing play button on viewer
• Importing media
• Switching to Edit page

DRs 16 is working without problems. Have not tested free version.

Looking forward to be able to use DRs 17

I've got the same issue and I dug a bit into it.

ATM I don't even see how this is even supposed to work.

AFAICT the CL context is always created without giving any properties whatsoever meaning it's never associated with a GL context, meaning that there is no way the call to the _clCreateFromGLTexture ( yielding the "Failed to register OpenGL texture to compute API" error in the logs ) can ever succeed.

Now, TBH, even in 16 I never had CL/GL interop working. That just never works for me. And doesn't even stand a chance to work if you're not using both GL and CL binary drivers. (i.e. CL binary only no way).

But in 16, it realized that CL/GL interop was not an option and fell back to manually uploading texture/buffers/... the old fashionned way. Basically copying from CL buffers back to CPU memory and then uploading it back to GPU memory in a GL buffer. Not great, but it's "safe" and works all the time.

Here I can see no trace that this option even exists ...

Thanks for digging into this. Can I ask how you made your determination that the issue was with the opengl drivers? Was it some thing in the logs or did you run an strace?

My understanding limited as it is, is that every one here has to have opengl loaded as that is how the desktop gets drawn. That is unless they are using vulkan which I believe will advertise it's self as opengl and then pretend to be opengl if that is what is required. Isn't libgl-amdgpu-pro-dri listed below the opengl driver? If I check system settings it says that the compositor is opengl 3.1.
--------------------------------------------------------------------------------------
libgl-amdgpu-pro-ext-20.20-1089974.el8.x86_64
libgl-amdgpu-pro-appprofiles-20.20-1089974.el8.noarch
libgles-amdgpu-pro-20.20-1089974.el8.x86_64
mesa-amdgpu-libglapi-20.0.5-1089974.el8.x86_64
libglvnd-glx-1.2.0-6.el8.x86_64
libglvnd-egl-1.2.0-6.el8.x86_64
libglvnd-gles-1.2.0-6.el8.x86_64
libgl-amdgpu-pro-dri-20.20-1089974.el8.x86_64
libgl-amdgpu-pro-20.20-1089974.el8.x86_64
mesa-libglapi-20.1.4-1.el8.x86_64
libglvnd-1.2.0-6.el8.x86_64
libglapi-amdgpu-pro-20.20-1089974.el8.x86_64
-------------------------------------------------------------------------------------

I wonder if BMD switched to using Vulkan rather than openGL which would make sense. Then neglected to mention it.

I went back and checked the system requirements and I see no references to any thing opengl/vulkan related. But I would be shocked if they didn't actually have some. I haven't updated my drivers since installing the OS, since updating AMDs damn proprietary drivers means I have to reinstall the OS from scratch. If any one running an AMD graphics card has 17 working on Linux can you please post what drivers you are using.

--------------------------------------------------------------------------------------------

Minimum system requirements for Linux

CentOS 7.3
32 GB of system memory
Blackmagic Design Desktop Video 10.4.1 or later
Discrete GPU with at least 2GB of VRAM
GPU which supports OpenCL 1.2 or CUDA 11
NVIDIA/AMD Driver version – As required by your GPU
A minimum NVIDIA driver version of 450.51.06 is recommended.
-------------------------------------------------------------------------------------------

BMD's silence on this is really starting to chaff my hide. If they made changes to their development/test machines or how they are compiling between 16 and 17 I wish they would come out and tell us what those changes were. Right now it feels like, hey try to guess what we did.

So.

Both OpenCL and OpenGL are GPU related APIs, but with different goals.

* OpenGL is for displaying graphics and stuff on screen.
* OpenCL is purely for compute stuff, doing math in the background using the GPU but completely unrelated to display.
* Vulkan is ... also more for displaying stuff, but completely unrelated here, nothing in Resolve uses Vulkan.

By default those two API operate completely independently from each other.

Now, there is an extension to both of these called "CL/GL interop". What this allows is to share data/objects between stuff you do in OpenGL and stuff you do in OpenCL. For instance to display on screen the results of some computation you made using OpenCL.

Without this extension, you have to get the results from your computation, copy it back from GPU to the CPU memory using OpenCL API. Then re-upload it to the GPU using OpenGL API for display which is inefficient (but safe). This extension allows to keep it in GPU memory at all times.

Now, with amdgpu, at least on my system, I can get OpenGL to work just fine, I also can get OpenCL to work just fine, but I _cannot_ get the "CL/GL interop" part working at all. And with resolve 16, it would just fall back to the "inefficient" method and still work just fine.

And I know the issue in 17 seems to be related to the interop because of the log :

Code: Select all

[0x7fcfc90ab700] | DVIP                 | ERROR | 2021-01-30 18:18:16,499 | Failed to register OpenGL object for OpenCL interop: CL_INVALID_CONTEXT.
[0x7fcfc90ab700] | UI.GLTexPool         | ERROR | 2021-01-30 18:18:16,499 | Failed to register OpenGL texture to compute API.

Where it clearly tells you it's trying to share an OpenGL object with an OpenCL context and failing.

I also analyzed what Resolve is doing (using a debugger) and can't even figure out where it tries to enable interop at all ... AFAIK it's not even trying ...

I went and did some more digging and there are references to "CL/GL interop" goimg back to at least 2014 in the AMD SDK so it won't be some thing AMD snuck in, in a recent driver so updating the drivers likely won't help.

This feels like some thing the compiler should be screaming about. "Whatcha doin' son? Tried tto initialize X with out first calling Y. Pffff" kind of a thing. I guess we are just flat screwed until BMD deems to look at it.

Thanks for your response.

Yeah, it would be nice to have some official BMD comment on this :/

Actually has _any_one_ managed to run 17b7 on linux with AMD / OpenCL ?

EDIT: I also tried with a Nvidia card with OpenCL and same issue. (works fine with CUDA, but forcing OpenCL mode crashes).


And huh, compilers also most definitely don't catch that kind of logic error ...

Thank you guys for researching about this issue.

EDIT: I also tried with a Nvidia card with OpenCL and same issue. (works fine with CUDA, but forcing OpenCL mode crashes).

The same thing is happening with me.

The CL vs Cuda part is interesting. Apples M1 platform is all in house so I would have to assume that it is CL rather than Cuda. It is hard to say how much code is shared between the different versions but hardware initialization would be a part that isn't.

No because Apple has its own thing (who would have thought), called "Metal".
And my guess is Resolve would be using that.

[Shrinivas Ramani]

Please try DaVinci Resolve 17.0 Beta 8.

You will need to download proprietary manufacturer drivers and a clean driver installation process.

So beta 8 allows my NVidia card to run in OpenCL mode just fine AFAICT. I also see in the logs that GLInterop was initialized.

My AMD card doesn't crash anymore but also doesn't display any media. I can see in the logs the GLInterop init failed and there is apparently no fallback to operate without interop like v16 supported.

[Shrinivas Ramani]

Sylvain

Can you post a link to a diagnostic log archive for the AMD graphics card issue? You can create it on the desktop from the Help menu after you see the blank display.

Merci
Shrinivas

See link in PM.

Currently I have the default amdgpu OpenGL stack from upstream and the OpenCL drivers from AMD.

As I explained in another thread, I tried for a long time to get CL/GL Interop working to no avail. (I'm a sw dev and I also do CL / GL software so I'd love to get it working ...). Attempts to use the GL stack from AMD result in worse results (most often I can't even get desktop to start and given how much of a mess it makes overwriting the working upstream driver I'm not keen on switching regularely). AMD pretty much doesn't care about the RX500 line anymore and due to which PCIe lane it's hooked up, it seems to cause issues. (I also can't get ROCM to work either for instance).

OpenCL and OpenGL work fine independently, just can't share objects.

So my question here would be mostly : Is working Interop a hard requirement for v17 (it wasn't for v16) or will there be a fallback mechanism ? And if the latter, is that fallback mechanism already in place (in which case I can continue and try to see why it's not kicking in), or is it upcoming (In which case I'll just wait).

Cheers,

Sylvain

There at least seems to be some trace or hope for fallback, although doesn't seem functional for the time being.

I tried adding :

Code: Select all

Local.GPU.GLComputeIO.Enabled = 1
Local.GPU.GLComputeIO.API = OpenCL
Local.GPU.GLInterop = 0


to my config but although init works ... it then tries to use interop on a texture anyway later on and fails

Please try DaVinci Resolve 17.0 Beta 8.

You will need to download proprietary manufacturer drivers and a clean driver installation process.

Thank you guys for working on the issue.

Succes

17.08b (Studio) now works fine on my installation. It now plays video fine w/o crashing.

Ubuntu 20.04.2LTS
AMDGPU-Pro drivers from AMD website.
RX580 8GB
Ryzen 7 2700X
32GB RAM

@MicamDK

Could I ask you to create a log archive (from the Help menu in DR) of your working setup ?
(So I can try to compare with mine)

Working well so far on ,mine as well. Thank you to BMD for looking at this.

@MicamDK

Could I ask you to create a log archive (from the Help menu in DR) of your working setup ?
(So I can try to compare with mine)

Did you upgrade to the new version?

Just a side note. I could not get 6k RAW to play back smoothly no matter how downrezed, optimized and cached I made it in 16 with my RX580. I have two projects that have been stalled forever because of this. Now it is just sooooo silky smooth.

I have been desperately trying to get my hands on an RX6800XT but .... now maybe I can wait until they are available and the the prices come down a little.

Here you go. I might add that it works (incl. with the SpeedEditor), but startup after loading a saved project is very slow.

@MicamDK

Could I ask you to create a log archive (from the Help menu in DR) of your working setup ?
(So I can try to compare with mine)

Did you upgrade to the new version?

Yes. Beta 8 works (the older beta's did not).

@MicamDK

Could I ask you to create a log archive (from the Help menu in DR) of your working setup ?
(So I can try to compare with mine)

Did you upgrade to the new version?

Thanks.

So I decided to retry the amdgpu-pro driver (I had tried previous drivers in the past with no success, but never the 20.45 latest ones), and to my surprise, that actually worked this time, CL/GL interop is working.

And that was enough to be able to start 17b8 !

So I went ahead and just placed an order for Studio I don't really need its feature, but it's affordable and just wanted to show my support for companies that release linux version of their products.
Apparently it's going to take a while before I actually receive though if I understood correctly.

I would still love to hear about BMD dev if a fallback for setup without working CL/GL interop like there was in v16 is planned or not. Don't get me wrong, I think it's a reasonable expectation to rely on it and not faulting BMD in anyway if they don't plan on supporting it, but although I'm on ubuntu 20.04 right now and that has the drivers I need from AMD, I might switch distrib or version to one that AMD doesn't provide their driver for and then I'd be back with a working CL + GL but without interop.

Glad it is working for you. Most distros are a variant of Redhat or Debian so you can probably get the appropriate AMD drivers to run. Unless you are running that distro that compiles every thing from scratch. The other option is to dual boot which is what I do. I have Fedora on one disk and then Centos on another. The Centos one once I got it working never ever, ever, ever gets patched or uodated beyond resolve it's self and has nothing extra beyond some codecs installed. Dual booting sucks but it's what I have for now.

Sylvain

Can you post a link to a diagnostic log archive for the AMD graphics card issue? You can create it on the desktop from the Help menu after you see the blank display.

Merci
Shrinivas

So 17.b8 works MUCH greater, less overall crashes. It feels much more responsive too in opening and switching tabs. It still takes about a minute or so after opening before loading thumbnails vs near instant with 16.2.8. ie it opens faster but takes longer before you can actually use it.

Thanks for getting this working. PS Working on Manjaro easily. Speed editor too, plug and play.