OpenCL Image Support For Gallium3D's Clover

[phoronix]

Phoronix: OpenCL Image Support For Gallium3D's Clover

While AMD hasn't been doing much work lately on the Clover-based OpenCL support with focusing their open-source OpenCL efforts around ROCm / Radeon Open Compute, Edward O'Callaghan has been working on some much-needed love for the Clover OpenCL Gallium3D state tracker...

http://www.phoronix.com/scan.php?pag...-Image-Patches

[haagch]

"some basic applications" == https://www.youtube.com/watch?v=-R-r0CEub74

[Serafean]

"shifted away from clover"? This means that clover is more or less dead in the water? Thus implying that opensource OpenCL is a fantasy?

[darkbasic]

Please, please keep working on it.

[89c51]

Will this work on r600g cards or radeonsi only?

[pal666]

Thus implying that opensource OpenCL is a fantasy?

thus implying that opensource opencl for amd cards will be done via roc

[schmidtbag]

So, is this why luxmark fails for me on the open source drivers?

[timofonic]

Why is OpenCL still relevant? Why not merge it along with other Khronos Group technologies within Vulkan? About sound, AMD did GPU accelerated sound stuff too :P


SOSNICK-PEREZ, Marc; HSU, William. Real-time finite difference-based sound synthesis using graphics processors. The Journal of the Acoustical Society of America, 2013, vol. 134, no 5, p. 4220-4220.


THOUTI, Krishnahari; SATHE, S. R. Comparison of openmp & opencl parallel processing technologies. arXiv preprint arXiv:1211.2038, 2012.


NES Project: Large Scale Synthesis on GPUs

Some already implement certain stuff:

- AMD TrueAudio Next
- Nvidia's VRWorks Audio

[schmidtbag]

Why is OpenCL still relevant? Why not merge it along with other Khronos Group technologies within Vulkan? About sound, AMD did GPU accelerated sound stuff too :P

The major advantage of Vulkan (besides easier implementation) is lowering CPU usage, but for most cases that still use OpenCL, that's not really a requirement. Unlike graphics, I don't think most OpenCL tasks require realtime processing, so CPU overhead is pretty much a non-issue. Basically, you just give the GPU some complicated thing to process and then it takes care of the rest by itself; it isn't constrained to accomplishing the task within a certain time frame and it doesn't do as much back-and-forth communication to the CPU (compared to graphics). I figure that's why there's that FirePro GPU out there with it's own SSD controller - it effectively allows the GPU to work independently.

[bridgman]

"shifted away from clover"? This means that clover is more or less dead in the water? Thus implying that opensource OpenCL is a fantasy?

Clover is not dead in the water (unless everyone in the community decides that it should be), it's just that our efforts shifted a year or so ago from clover to rebuilding our proprietary OpenCL stack on top of ROCM and open sourcing the remaining closed-source bits.

The first step along the way was replacing the proprietary/third-party C-language parser with clang (done); remaining tasks include:

(a) modifying OpenCL to run over ROCM rather than the current back-end (which is based on the proprietary OpenGL driver), and

(b) using the LLVM-based native compiler (also used in ROCM/HCC and the open source Mesa drivers) rather than the proprietary shader compiler.

We are aiming to have a developer preview of the modified OpenCL stack (still closed source runtime but using a lot more open source code) around mid-December.