Hi everyone,

It's time to ressurect this thread a bit. I'd love to be able to dedicate some time to working on OpenGL support for MorphOS. Based on feedback and what I've observed myself, I'm gonna outline a couple of possible targets for OpenGL improvements:

Target 1: Implement the fixed-function OpenGL pipeline as shaders

This would fix a number of a small issues that are unlikely to get fixed otherwise.

For R200, the hardware does implement the fixed-function OpenGL pipeline in hardware, but it has a few bugs and omissions, and these bugs and omissions can't really be worked around without either completely disabling hardware support for the vertex side of the OpenGL fixed-function pipeline, or as the heading suggests, implementing it as shaders.

For R300, there's no hardware support for the fixed-function OpenGL pipeline, and the current driver implements it as two static shaders, a "simple" one that handles just the basics, and a "complex" one that partially handles OpenGL lighting too. This implementation misses quite a few things, and the work required to make it correctly support everything would be almost the same amount of effort as implementing it generically in TinyGL, where other hardware could also benefit from it.

R600 (and potential newer hardware) support would also benefit from this, as it's basically a requirement for any hardware from R300 and up.

Completing this task would fix a bunch of smaller issues, such as:
- Texture coord generation (which I believe is used by Doom 3)
- Fog
- Texture comparison
- OpenGL lighting
- ... and probably a bunch of other things.

Target 2: Framebuffer objects

While this feature has only been part of core OpenGL since version 3.0, it has been available as an extension before then, and it is (mostly) hardware independent and can thus be implemented for any hardware currently supported by MorphOS, even if it predates OpenGL 3.0 by quite a bit.

The gist of this feature is that it allows applications and games to draw into other things than just the display buffer, commonly a texture. This can for example be used to create bloom effects, mirrors, water reflections and many other things.

Here is a Youtube video I found with a somewhat technical, yet not too technical, explanation of how to do water reflections with framebuffer objects.

Target 3: Shaders

This one probably doesn't need too much of an introduction or explanation, but in short, shaders are what (mostly) replace the fixed-function OpenGL pipeline with a programmable one. Shaders are small programs that run on the graphics card to control how input vertex data gets transformed and how final output pixel data gets calculated, split up into vertex shaders and fragment shaders respectively.

Hardware wise, only R300 and newer can fully support OpenGL 2 shaders, however R200 can partially support them too.

Fully implementing shaders to specifications is a huge task. Therefore I suggest working more towards getting the most common functionality working correctly, and then adding extra functionality later if it turns out it's needed for an interesting application or game. Note that MorphOS already has some (quite partial) support for OpenGL shaders on R300 and R400 only. This would need to be extended to fully implement the OpenGL API, to support more of the OpenGL Shading Language and handle more complex shaders, and finally also to support R200 and R500 hardware.

Target 4: Programs

OpenGL programs are a precursor to OpenGL shaders, and is more like an assembly-like version of shaders. They were never used widely, but Doom 3 used them. I'm not 100% sure if the Doom 3 fork that Cowcat's MorphOS port is based on has been updated to use shaders instead, but from a very, very quick glance, it doesn't look like it. If so, implementing OpenGL programs would be a requirement to fully support Doom 3.

Target 5: R600 driver

A TinyGL driver for the R600, R700, Evergreen and Northern Islands families of Radeon chips. Writing this driver would depend on the first target listed above, implementing the fixed-function OpenGL pipeline as shaders, to avoid doing duplicate work.

Such a driver would enable OpenGL support for many commonly available PCI Express graphics cards, which can be used in for example the Sam460, the X5000 or PCI Express Powermac G5s. This hardware also supports many more features required for OpenGL 3 and beyond.

Other targets

I've probably forgotten about some things here, so if you have any suggestions for anything else you'd like to see done, let me know and I'll add it in.

Notes about hardware names used above
R200 refers to the R200 family of Radeon chips, and includes every Radeon chip that's called R2xx or RV2xx except RV200. Radeon model numbers for R200 are Radeon 8500 up to and including Radeon 9250. Mac Minis and most Ibooks use this. See the Wikipedia page for Radeon R200

R300 refers to the R300, R400 and R500 family of Radeon chips, which are all supported by the same driver. Chip names for these families are all either R3xx, RV3xx, R4xx, RV4xx, R5xx or RV5xx. Most (if not all) Powerbooks supported by MorphOS use this, as well as Powermac G5s in standard configurations. See the Wikipedia page for Radeon R300, the Wikipedia page for Radeon R400 and the Wikipedia page for Radeon R500

R600 refers to the R600, R700, Evergreen and Northern Islands family of Radeon chips, which will all be supported by the same driver. Chip names for these familes are R6xx, RV6xx, R7xx, RV7xx, Antilles, Barts, Caicos, Cayman, Cedar, Cypress, Juniper, Cypress, Hemlock, Redwood and Turks. Note that Antilles, Cayman and Hemlock will not be supported. These chips are only used in the very high end Radeon products from these families. They require a disproportionate amount of effort to support compared to potential gains.

The bounty
I gotta admit that I'm really unsure how to organise this bounty, so I'd like you guys' input on this. We can either sort of merge all the targets (maybe minus the R600 driver) into one, and then I work on them in the order that makes the most sense for me, or we can do individual bounties for each target. I think that most people don't really have any preference as to what they'd specifically like to see done, just as long as it means support for more modern games and applications, which would speak in favour of doing a merged bounty. We could also do sort-of a hybrid, where we have a merged bounty, but when you contribute to the bounty, you get to vote for which target you'd like to see completed first. So please leave some feedback everyone, tell me what you'd like to see!

Making progress updates end results available
If we end up doing this bounty, I'll write a weekly progress report here on MorphZone, as well as make beta updates available for anyone who would like to test my work as it progresses.