Universal data exchange module

PS: Number one goal for us to get video decoding by the GPU. An OS that cannot play youtube videos in acceptable quality is…. multicore support might help here in the near future.

It would be interesting how someone got it done to get some hardware GPU support for the Raspberry 3. Who was it?

The source code to the Khronos module and the changes to the userland Rpi1-3 GPU libraries are available here.
There’s no OpenMax IL (video codec interface) or MMAL (camera interface) support. The Rpi GPU userland source code is here.

I don’t know how it was done. I just used it to port a few things.
An example of a game (Dark Places – OpenGLES version of Quake 1) that uses it is available here.

The port of SDL2 (full screen only) for Rpi 1-3 uses it. One draw back of using the GPU on RISC OS is RISC OS knows nothing of the GL surface, it just overwrites what’s on screen. I believe it needs hardware overlay support in the desktop for it to work as a normal window.

I’d imagine to get Youtube working in a Web browser on RISC OS there is a whole heap of stuff that needs changing in the OS.

@ Stefan Fröhling

About 3D I mean that in RISCOS we don’t have native 3D SWI calls, only 2D vector calls. OpenGL, Vulkan, Mesa are high level 3D libraries. What we need is the hardware access to the GPU. It would be interesting how someone got it done to get some hardware GPU support for the Raspberry 3. Who was it?

I see what you mean now. Ok just for the record, as I described before OpenGL, Vulkan, Mesa are not High lever APIs, they are “Full-Stacks”, they mostly are Specifications, as a matter of fact you won’t find code at opengl.org for example. The OpenGL stack used on Linux is directly implemented and built by either AMD, NVidia or Intel, following the OpenGL specifications.

They basically create user-space APIs, but they are very low level components because they need to access the hardware directly. So please let’s not be confusing, there is no separation between OpenGL API and the driver they are part of the same stack.

So, if I understand you correctly, you want to build just the driver component and create an SWI based API, so that more programming languages (for example Assembly) could use it directly instead of having to go through wrappers and binders as it happens on Linux for example. In such a case I think there is more work to do, but the idea could actually be good as it could be used to accelerate Mesa for RISC OS if it works and if it’s done right.

@ Chris Gransden

Thanks for the pointers to the source! :)