Since a while now I have been working on OpenGL on AmigaOS. Progress has been slow so far – there have been a good number of fundamental issues to be cleared up.  For starters, let me summarize the goals:

1. Provide a hardware-accelerated OpenGL for applications, games, and the operating system.
2. Provide a driver interface with maximum flexibility. We do not want to count exclusively on Gallium3D as a basis for drivers, although it will be a fundamental one.
3. Provide a low-level API that does not depend on high-level constructs like Windows or Screens. While it should be possible to render to these, it should not depend on any of them.
4. Be able to upgrade to the latest OpenGL version, depending on driver support.
5. Support multi-threading and multiple CPU’s.

Let’s look at these goals. We want to provide a hardware-accelerated OpenGL that can be readily used by applications and games alike. We would also like the operating system to be able to take advantage of this. Workbench should be able to draw its stuff with OpenGL hardware-acceleration, and even Intuition should be able to use it. There is no point in restricting such an important part to a mere application/game interface. It has to become an integral part of the system.

Early software-only prototype

The internal driver interface is designed to be usable with or without Gallium3D. Obviously, the focus of our work will be Gallium-based, but what if there is a graphics card that does not support the required level of shader support to be able to work with Gallium? For this purpose, opengl.library (the central hub of the OpenGL system on AmigaOS) is able to load and operate drivers that only provide a minimal set of internal functions plus the required entry points for OpenGL. That way, it is possible to use a Mesa based driver, or even a completely custom driver, for hardware that is not supported by Gallium3D.

Our interface is intentionally very low-level. There are two major reasons for this. At first, developers will likely never encounter or use the low-level interface directly. They’ll more likely use a high-level API like EGL or SDL or even GLUT instead. Which doesn’t mean that the low-level API is clumsy or awkward to use. It is merely building on very low-level blocks – for example, it only renders into bitmaps and nothing else. Of course, bitmaps are at the base of all AmigaOS graphics and GUI constructs. To render to a screen, one can supply two bitmaps for ScreenBuffer-type double buffering. For a window, there’s the classic solution of using the graphics card blitter to copy the image into the window after rendering, or, on compositing enabled screens, to render directly into the window’s own bitmap. In any case, being low-level means that the API is future proof for any changes that might come to Intuition or Reaction.

Obviously, we want to be able to update drivers individually. The version of OpenGL support, as well as any extensions, will greatly depend on the driver. Most drivers support OpenGL 2.1 right now, including GLSL support. The exact possibilities depend on the hardware as well (a Radeon R100 will never support GLSL). The flexible driver interface will make sure, however, that individual drivers can be updated without having to update either the applications using OpenGL, nor opengl.library itself.

Finally, multi-threading and multi-CPU support is an important factor. If you are aiming at making a system an integral part of the OS, then support for multithreaded operation is as much a requirement as support of multiple CPU’s.