cl_khr_gl_sharing missing on ocl runtime (Ellesmere/Polaris/RX580)

[clapbr]

Trying to figure out why latest ROCm 4.2.0 won´t work properly with DaVinci Resolve (likely broken cl/gl interop), clinfo reports:

Device Extensions cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_image2d_from_buffer cl_khr_subgroups cl_khr_depth_images cl_amd_copy_buffer_p2p cl_amd_assembly_program

Simply replacing only libamdocl64.so from an older ROCm (3.3) makes Resolve work, with latest mesa. No need for pro libGL. This is what clinfo reports with 3.3 ocl runtime:

Device Extensions cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 **cl_khr_gl_sharing** cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_image2d_from_buffer cl_khr_subgroups cl_khr_depth_images cl_amd_copy_buffer_p2p cl_amd_assembly_program

4.2.0 seems to be missing cl_khr_gl_sharing, at least for Ellesmere. Tried both binary build and build from source, same results. Maybe this is related to why GUI apps broke, no idea.

[vsytch]

Thank you for opening this issue.

Due to issues with Mesa-GL, we needed to disable the CL-GL interop for the ROCm stack.

The interop capability should still be enabled when using OpenCL included with the amdgpu-pro package, as that one will interop with the proprietary AMD OpenGL driver.

[clapbr]

Thank you for opening this issue.

Due to issues with Mesa-GL, we needed to disable the CL-GL interop for the ROCm stack.

Any plans to fix it in the future? It works to this day with 3.3 and latest mesa from git, so is it really a Mesa-GL issue? Since AMD contributes to mesa directly shouldn't be a problem to handle this if the cause is known.

The interop capability should still be enabled when using OpenCL included with the amdgpu-pro package, as that one will interop with the proprietary AMD OpenGL driver.

I'm aware, was using pro CL+pro GL but it performs significantly worse in DaVinci. FWIW with latest mesa+rocm 4.2 libs+rocm 3.3 opencl runtime I get better performance mostly rendering Fusion compositions on the timeline than with amdgpu-pro. (case I tested went from 17fps to full 29,97fps, cache disabled).

Thanks for the quick reply.