Open clapbr opened 3 years ago
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.
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.
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.