OpenCL Remains One Of AMDGPU-PRO's Main Advantages, Can't Wait For It To Be Open

[phoronix]

Phoronix: OpenCL Remains One Of AMDGPU-PRO's Main Advantages, Can't Wait For It To Be Open

While many in our forums and other Linux communities want to see "AMDGPU-PRO die" or for AMD to stop supporting the hybrid/proprietary driver given the pace of RadeonSI development for OpenGL and the emerging RADV for (unofficial) Vulkan support, OpenCL remains one of AMDGPU-PRO's strongholds. AMD has been working on opening up their proprietary compute stack, but for now it's there. Here are some fresh AMDGPU-PRO 16.40 benchmarks versus NVIDIA in LuxMark, one of the real-world OpenCL workloads where the AMD blob does very well...

http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-OpenCL-Advantage

[bug77]

will still likely be a few months of work before it's really in shape and then potentially a few more months after that before it will be found out-of-the-box in the (non-rolling) distribution of your choice

"Likely" based on what? If bridgman has ever said something about opening up the Pro driver, I have certainly missed it.

[starshipeleven]

"Likely" based on what? If bridgman has ever said something about opening up the Pro driver, I have certainly missed it.

he said that they wanted to have an opensource OpenCL driver, which is admittedly not the same thing as opening the PRO driver itself.

[bridgman]

We don't plan to open up all of the Pro driver (specifically not the OpenGL part) but we are working on opening up the Vulkan and OpenCL parts.

For OpenCL the main tasks were moving from (a) third party proprietary C parser to clang, (b) back-end code-shared with OpenGL driver to ROCM, (c) proprietary shader compiler to the LLVM-based native (direct to ISA) compiler we also use with open source gfx drivers and HIP/ROCM stack.

The first step was finished a while ago; developer preview with the remaining tasks should come out some time in Dec (still closed source but with a lot of functionality moved out and replaced with open source code).

EDIT - never mind, Michael already had the details in his article.

[bug77]

We don't plan to open up all of the Pro driver (specifically not the OpenGL part) but we are working on opening up the Vulkan and OpenCL parts.

For OpenCL the main tasks were moving from (a) third party proprietary C parser to clang, (b) back-end code-shared with OpenGL driver to ROCM, (c) proprietary shader compiler to the LLVM-based native (direct to ISA) compiler we also use with open source gfx drivers and HIP/ROCM stack.

The first step was finished a while ago; developer preview with the remaining tasks should come out some time in Dec (still closed source but with a lot of functionality moved out and replaced with open source code).

EDIT - never mind, Michael already had the details in his article.

Ok, the basis for the "few months" Michael is talking about is what I was after.

[Pontostroy]

For opencl-pro on default amdgpu and mesa you just need 5 files from pro driver(3 libs, 1 symlink and icd config file), but anyway i wait for TAHITI support for opencl-pro, llibdrm_amdgpu from pro does not know TAHITI, libamdolc* has TAHITI strings

[treba]

Wow, full opencl support out of the box with free drivers sounds really really great. Hope to see this and HSA landing over the next year, so new AMD APUs should be incredibly fast for programs that use openmp alot (or do I mix up things?)

[bridgman]

The ROCM stack is the latest version of what we were calling the HSA stack, but extended to include support for non-HSA-compliant dGPUs:

https://github.com/RadeonOpenCompute/ROCm

[efikkan]

If only AMD dropped the "free" driver and rather open sourced the AMDGPU-PRO driver, then finally we could have the focus on one native driver instead of several bad ones.

[Evil Penguin]

We don't plan to open up all of the Pro driver (specifically not the OpenGL part) but we are working on opening up the Vulkan and OpenCL parts.

For OpenCL the main tasks were moving from (a) third party proprietary C parser to clang, (b) back-end code-shared with OpenGL driver to ROCM, (c) proprietary shader compiler to the LLVM-based native (direct to ISA) compiler we also use with open source gfx drivers and HIP/ROCM stack.

The first step was finished a while ago; developer preview with the remaining tasks should come out some time in Dec (still closed source but with a lot of functionality moved out and replaced with open source code).

EDIT - never mind, Michael already had the details in his article.

Is it safe to say that the official Vulkan open source driver will use LLVM for shader generation as well (like RADV)?