Excellent news ! Thanks to all for your work !

But can it run Crysis?

Before we lost a weeks worth of posts, we were talking about a bounty. As I said before, I will support. Is this something that can be set up in the "Bounties" section?

I’m glad someone has pulled this thread up again as Bigfoot seemed willing to take up the challenge of this bounty if we could set some acceptable rules.

We were talking about having certain applications/games as the target such as Doom 3.

For a proper bounty project to be set up via either MorphZone or WArMUp, you would need to define a description of what would be delivered so donors know what they would get.

bigfoot had shared this link: MorphOS OpenGL 2.1 status overview

Alternatively, there could be a "self-managed bounty", which would involve bigfoot simply setting up a Paypal link (or a link to a similiar payment service).

So it seems like about 50%, or more, of what OpenGL v2.1 is supposed to be capable of offering is currently either not fully supported, or only partially supported in MorphOS, from what bigfoot's chart shows. I have ignored the Colour Index Mode as that seems to be irrelevant, from what bigfoot states. So ...

Function status . . . . . Count . . . . . . Percent
Fully supported. . . . . . . . . . 12 . . . . . . . . . . . 2.2
Function exists . . . . . . . . . . 229 . . . . . . . . . . 41.6
Macro exists . . . . . . . . . . . . . 51 . . . . . . . . . . . 9.3
Not supported . . . . . . . . . . . 246 . . . . . . . . . . 44.6

On that basis, maybe we would need to know the timescale/effort/workload estimated to bring OpenGL v2.1 to the point where basically all, or at least virtually all of the essential components, or the most beneficial ones, needed to make it work as intended is completed, and for a basic cost for the work that it would require to manage this, to see if this is feasibly fundable with a bounty, I suppose?

Agreed, this looks like a big project. There should be priorities and the bounty should be allocated accordingly.

glTexGenfv is fixed ? That means Doom3 should look much better. I want test that.


Got bigfoot my tinygl observations/debug for VBOs ?

As my WarpOS projects and now MOS, my stuff tends to be used as test cases for libs/system bugfixes (and it never ends).

Quote:

Sorry, no changes have been done to texture coord generation in a long time.

Quote:

I did receive an email from you recently, but I'm a little bit behind on the emails right now - I'll get to it very soon :)

And as for my status page, unfortunately all the comments discussing and explaining it got lost.

However, just to clarify: I'm also using this status page as internal guidance for myself. I'm only marking something as fully supported when not only is it supported, but it's also been verified to work according to specs, and has a unit test associated with it to verify its real life functionality too. Much of what is marked as "function exists" is either fully implemented, or only missing minor things required for specs conformance, but not having an effect on pretty much any real world application.

I'm also in the (hopefully) near future gonna make some notes about how difficult certain features are to implement, since it's pretty much impossible to tell from the current status page.

@ bigfoot - Thanks for the quick update, and from what you've said, I'm quite hopeful that some seemingly important features can already be fairly easily marked as conforming to specs soon, and others will get worked on to improve OpenGL much further, once you have worked out what it will take/cost to implement them.

Any progress about this bounty?

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.