RISC OS Developer Forum - Open Source for ARM SoC #Raspberry Pi #Acorn
07-26-2021, 02:32 PM
RISC OS is missing a standard 3D API and drivers. In the past there have been numerous projects which have attempted to bring 3D rendering to RISC OS, but none had sufficient support or were restricted to a single platform.
The main ones I'm aware of are:
The main limitation of the Mesa ports is that access to the OpenGL APIs was via C/C++ only, since there were no bindings for other languages. From a design perspective, it would make the most sense to provide the OpenGL (or other) APIs via SWIs, since that would allow for a language-agnostic way to make these calls. We can still provide C APIs for ease of porting existing software. In terms of flexibility, allowing for different renderers to be swapped in below these APIs would allow for software or hardware rendering on any given RISC OS platform.
As a first step, the goal is to create (or port) a module that provides access to OpenGL 1.1 APIs from RISC OS. The next step is to connect that to an existing software and hardware renderer. Following that, more recent OpenGL APIs will be added, and a core goal is to maintain a port of Mesa with a 3D accelerant for the RK3399. This is already available in Panfrost, for Linux.
The main ones I'm aware of are:
- Software rendered OpenGL 1.x via a Mesa 3.x port from the early 2000s. This had an ARM code renderer and would work on machines of the time but the assembly needs updating for current compilers.
- Hardware rendered OpenGL 1.x via a Mesa 3.x port from 2005 for the Iyonix. This had a hardware accelerated renderer but would only work on the Iyonix with specific GeForce cards. Vertex processing was still done in software so although it could run games like GLQuake, it was fairly slow. I made this port.
- Hardware rendered "Khronos" driver for the Raspberry Pi 1-3, including a module which provides SWI access to the OpenGL API.
The main limitation of the Mesa ports is that access to the OpenGL APIs was via C/C++ only, since there were no bindings for other languages. From a design perspective, it would make the most sense to provide the OpenGL (or other) APIs via SWIs, since that would allow for a language-agnostic way to make these calls. We can still provide C APIs for ease of porting existing software. In terms of flexibility, allowing for different renderers to be swapped in below these APIs would allow for software or hardware rendering on any given RISC OS platform.
As a first step, the goal is to create (or port) a module that provides access to OpenGL 1.1 APIs from RISC OS. The next step is to connect that to an existing software and hardware renderer. Following that, more recent OpenGL APIs will be added, and a core goal is to maintain a port of Mesa with a 3D accelerant for the RK3399. This is already available in Panfrost, for Linux.