Etnaviv Gallium3D May Eventually Tackle OpenCL

[phoronix]

Phoronix: Etnaviv Gallium3D May Eventually Tackle OpenCL

Two developers from the Pengutronix embedded Linux company out of Germany presented at this week's Embedded Linux Conference in Europe. There they talked about zero-copy video streaming on embedded systems, and as part of that, the Etnaviv open-source graphics driver...

http://www.phoronix.com/scan.php?page=news_item&px=Etnaviv-OpenCL-Future

[schmidtbag]

That'd be cool if they got this to work. To my knowledge, there are currently no ARM GPUs with OCL+Linux support, so this could give the platform some leverage.

To clarify, I know the Vivante GPUs support GLES 3.1, but what's the highest version of OpenGL that they support? I originally thought 2.x was the highest but I haven't bothered to look into it in a long while.

[shmerl]

Given that OpenCL is now being folded into Vulkan, they should better concentrate their efforts on Vulkan implementation.

Also, Etnaviv is missing from Mesa's features.txt. Who can add it there?

[Guest]

schmidtbag OpenGL ES 3.0 roughly corresponds to OpenGL 4.0 , but it depends on the hardware requirements of the API (e.g AMD northern islands/Evergreen doesn't support 64 bit floating point, so that's why no OpenGL 4 support yet).

[vasc]

Given that OpenCL is now being folded into Vulkan, they should better concentrate their efforts on Vulkan implementation.

OpenCL is not replaced by Vulkan. Vulkan is a lower-level OpenGL. Vulkan Compute is just a GLSL replacement. But both OpenCL and Vulkan Compute use SPIR-V as a low-level binary representation.

[shmerl]

OpenCL is not replaced by Vulkan.

It will be. See http://hexus.net/tech/news/software/...ge-single-api/
I.e. not exactly replaced by Vulkan as is, but superseded by Vulkan + whatever new they'll add.

[vasc]

That's CLNext, whenever it is published, if ever. The spec isn't ready, there are no implementations, it's pure vapor.

[shmerl]

The spec isn't ready, there are no implementations

But it will be Vulkan based, that's already clear. Investing efforts in Vulkan is going to be useful either way, not just for compute.

[vasc]

If whoever implements Vulkan implements a SPIR-V bytecode runtime for the Vulkan Compute then yes much of that can be reused for OpenCL. Regardless if it's OpenCL 2.0 or CLNext or whatever. If you have the SPIR-V bytecode runtime, then all you need is probably an OpenCL C/C++ parser to SPIR-V bytecode compiler, which is machine architecture independent and only needs to be written once for all the graphics hardware you need to support, and perhaps minor changes to the SPIR-V bytecode runtime for OpenCL exclusive functions if any.