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.

@bigfoot: Thanks for your detailed and meaningful description of the individual targets and also for your time to bring this on!

As far as I got it Target 1 is a prerequisite for Target 5. Can the other ones be pursued independently or are there dependencies among them too?

For my part I would contribute to Targets 1 + 3 and with a larger ammout to Target 5.

Quote:

Yes, the others can also be done independently. However, without shaders, you won't be able to use more than one rendering target with framebuffer objects.

Quote:

Thank you, I appreciate it! I'm also happy to see interest in the R600 driver! :)

@bigfoot

In a previous post you mentioned that OpenGL 2.1 is approximately 50% implemented. Is it fair to say each of these 5 targets represent 10% of the work required or would you weigh them differently? This would be helpful to know when contributing to each Target, that is, if the bounty ends up being organized that way. Thanks for the update!

I'll happily contribute to all targets, as far as I can !
Thx messire Bigfoot !

Quote:

It's a bit dangerous to assign a specific percentage number to this, and I think the 50% number came from the number of functions that are required in OpenGL 2.1, and which also exist in TinyGL.

However, shaders is definitely the big one here. Once that one is done, we'd be pretty close to OpenGL 2.1 functionality, in the sense that the remaining missing functionality will be relatively small in comparison, at least if we disregard the functionality that's very rarely used, if ever, and which I'm not currently planning to implement.

Actually, of the 5 things mentioned, only really shaders has a direct relationship to achieving OpenGL 2.1 functionality. Framebuffer objects aren't part of (core) OpenGL until OpenGL 3.0, and OpenGL programs were never part of (core) OpenGL, it only exists as an optional extension. Implementing the fixed-function pipeline as shaders could count towards OpenGL 2.1 functionality, but it would mainly fix existing functionality to work correctly in all cases, rather than add new functionality. The R600 driver is of course unrelated to reaching the OpenGL 2.1 feature level, as that can be done with the existing R300 driver.

But to attempt to answer your question, and please don't understand this as any sort of exact estimate, but I'd say that shaders probably represent something like 60% of the work to go from MorphOS' previous state to OpenGL 2.1 (again, with the exceptions mentioned above), and implementing the fixed-function pipeline as shaders would probably represent another 20%. The remaining 20% is spread over various not-too-difficult tasks, which range from "pretty simple to do" to "this will take a bit of time, but it's mostly just tedious work, there's no real challenge in it".

Thanks for the explanation and rough estimates!

@bigfoot
many thanks for explanation and nice plans.
I like to contribute to the bounty if it will be.

And I have some questions. I am not developer or expert on computer graphics, but want to ask, what part of graphics cards hardware this future MorphOS OpenGL implementation utilize?

R200 - R500 have in HW spec (techpowerup.com):
Pixel Shaders
Vertex Shaders
TMUs (texture mapping units)
ROPs (render output units)

R600, Evergreen, Northern Island have:
Cores (=shaders?)
TMUs
ROPs

So what is most important for TinyGL/OpenGL speed in MorphOS? Can MorphOS utilize all Shaders or cores?
Please, in short is enough. I make often a benchmarking and it helps a lot.

Excellent news! Thanks bigfoot for explanation and motivation to these projects.

I would contribute to all target of course

as always, i'm in ;)
I would like to see target 1+3+5 as one big bounty and 2+4 as additional bounties.

Quote:

I'll try to make it as short as possible :)

Prior to R600 (so up to and including R500), vertex shaders and pixel shaders are handled completely differently by completely different parts of the hardware. Starting with R600, Radeons implemented what is known as unified shaders, where it's the same hardware that executes every kind of shader. That's why you see this difference.

When it comes to performance, it's pretty hard to generalise just based on specs alone. For current MorphOS OpenGL applications, the limiting factor in OpenGL performance is almost always memory bandwidth. For future ones that will use complex shaders, having more and higher clocked shader cores will become more important than memory bandwidth.

As for actually using all the cores, that is pretty much transparently handled on the hardware itself. The driver doesn't program individual cores, it just submits a job to the GPU, and the GPU internally handles splitting up this job into smaller parts and handing those parts to individual cores. So short answer: Yes, MorphOS will be able to handle any shader core count.

Quote:

+1 from me on this!

I haven't booted up any MorphOS system in probably almost 2 years, and I'm on a very limited retirement budget, but I'll gladly donate to this proposed TinyGL bounty, specially if it will make it easier for X5000 and SAM owners to dual boot AmigaOS4 and MorphOS on the same video card, because I think that allows more users to use MorphOS more often, and encourages more development for MorphOS software and games. With all the problems surrounding Hyperion Entertainment and further development of AmigaOS4, making it easier for existing AmigaOS4 users to try out MorphOS should result in SOME new users, and maybe one or two new developers, or porters of software/games.

I don't understand all the technical differences between the latest Nova graphics for AmigaOS4, and TinyGL for MorphOS, so this might be a stupid question, but could collaboration with the author of the Nova graphics that is funded by A-Eon, and/or AmigaKit help improve video drivers for MorphOS, and cross platform development for both MorphOS and AmigaOS4? Seems to me that both Big Foot, and Hans of Nova, are really talented video driver developers, and it is a shame if they can't help each other to make development on both platforms better and easier, and porting between systems much easier.

> specially if it will make it easier for X5000 and SAM owners
> to dual boot AmigaOS4 and MorphOS on the same video card

The bounty proposal goes up to TeraScale 2 generation, the predecessor of TeraScale 3. Modernish 3D support by OS4/Enhancer starts with GCN1 generation, the successor to TeraScale 3.

Quote:
@bigfoot
many thanks! This is perfect information.
Good luck with your work!

Great news @bigfoot!

I will contribute for sure.

[ Edited by MoerBoer 30.05.2022 - 10:27 ]

@ bigfoot - I'll also support this bounty once it gets initiated, as far as I see it, work on shaders is an absolute must have implemented for the necessary improvements that will advance our GFX hardware's capabilities.

For me i have a preference for "Target 2: Framebuffer objects" (can use by SDL2 OpenGL renderer driver) and shaders and and.. all

Same here i will contribute.

I recently had a chance to try the updated Aquaria port from

Aquaria_1.002 @ MorphOS Storage

Does anyone know why the in-game bubbles are "square" and not sort of round there ? :)

Maybe something missing in TinyGL regarding stencil support ? It would at least be nice to have glitches like this fixed in a future update I guess ...

Edit: OK, never mind, seems that we tested it with an incomplete dataset, TinyGL and the game seems to be fine in that regard ...

Quote:

The question here is really how big will that bounty be?

For the whole thing were are talking 4 figures for sure (5 or 6 once we convert it into ZAR ;) ), but what about each step on its own? And which of the steps even make sense without the others?

I will chip in something but it might be a good idea to get the bounty started before people really feel the recession.

Quote:

I definitely appreciate the support! But as has already been stated in another reply, this wouldn't really overlap with graphics hardware typically used by AmigaOS 4 users.

Quote:

When it comes to graphics and graphics drivers in particular, the two systems are to the best of my knowledge completely different. There isn't really any reasonable way for something like that to work, unfortunately.

Very interesting to read that a kind of mini shader functionality already exists on R300 drivers.

If somewhat old Radeons can have some support from R300 shader code allowing the missing functions to be implemented, I would bet for it: Besides non-duplicated work, probably it would increase performance leaving normal CPU for other tasks (not sure about that).


Dhewm3 by default uses GL_ARB_vertex_program and GL_ARB_fragment_program extensions.

The rest of needed functionalities are located in RenderSystem_init.cpp and draw_arb2.cpp sources.

It was not my intention to push developers to a humongous work but my "potato port" might have some use after all.

Quote:

Yeah, that is a very good question. At least there seems to be enough interest to continue with this, and the majority seems to want to be able to donate towards individual targets, so I'll figure out price targets for each individual task and then set up something for handling payments.

Quote:

Only really the R600 driver more or less depends on having the fixed-function pipeline implemented as shaders. It can be done without it, but it just means a quite big amount of duplicate work.

Everything else can be done individually really.

Quote:

Well, fingers crossed for no recession, but good point nonetheless :)

Quote:

There was indeed already some work done towards shaders for R300 (and R400, which is almost identical in that regard), but it never really left the experimental state. There's definitely lots of work still to be done to have it usable in general.

Quote:

Everything that would be handled by implementing the fixed-function pipeline as shaders is already handled on the GPU today, so it wouldn't change anything from a performance point of view.

What could increase performance, and I want to make it clear that I'm speculating here, but for example in Doom 3, I imagine that it is doing interpolation between model frames currently. Without shaders, it has to do this with the CPU for every frame. With shaders it could do this interpolation on the GPU itself, which would not just save CPU power, but also allow for the models to be uploaded to the graphics card just once, instead of once every frame.

Quote:

Thank you :)

Quote:

Sometimes a push is required :) And I'm fairly sure plenty of people are enjoying your work too, so it's definitely useful!

@cyfm
Quote:

Look round here, at least as far as I have played, which is not much yet.