With R600g Now Supporting OpenGL 4.1, See How The Open-Source Performance Compares To AMD Catalyst

[eydee]

Why is that any better than just announcing what is actually supported? It will be broken for any apps that need the fp64. Linux is used by more than just gamers. What about convincing the game developers to only request the extensions they need?

Thing is, GLX_EXT_swap_control is already faked. It affects all cards, and all applications that have vsync control. Then we don't even have GL1.1 compliance it seems. Why are higher versions advertised?

Convincing developers for future titles is good idea, except you will run very few future titles on R600 cards. This would be for present titles, that actually could run, but developers would not bother patching. And if any application suffers, the number of bug reports would show how much broken it is, or if it affects 2 people and an unknown application, and can be left as wontfix. (Or implemented as emulation.)

Who cares about nearly 6 year old hardware?

People who read articles about it and comment on them maybe. Other reason would be called trolling and handled by the infamous troll spray.

[bridgman]

People who read articles about it and comment on them maybe. Other reason would be called trolling and handled by the infamous troll spray.

Where can I buy troll spray ? I ran out a couple of years ago...

[Premislaus]

Who cares about nearly 6 year old hardware?

I have a laptop with A6-4400m (VLIW4) and 7670m (VLIW5). I'm going to use it until stops working. Previously I had a desktop with Athlon 3500+ for 6-7 years until chipset broke down. I bought this laptop in 2013. A lot of games running on it, internet, office suite. Only new kernel versions support this hardware properly. The main disadvantage of this machine is that the dual graphics never worked (on Windows: stutter, tearing, FPS drops, texture flickering). That's why I play on a dedicated GPU, but does not have double precision compared to the integrated GPU.

[agd5f]

I personally don't like to create an if/ifdef hell in my code like you proposed, and make it hard to maintain. I expect atleast OpenGL 4.3 support to be just there when targeting DirectX11/OpenGL4 hardware and OpenGL 3.3 for the older. None cares about supporting weird driver/hardware setups.

No ifdef hell, just query and use the extensions you need rather than just requiring 4.3. No need to support multiple code paths.

[agd5f]

Do you mean initializing an OGL 4.0 context and then utilizing required extensions without fallbacks? (for example TBOs as a fallback for SSBOs absence, etc) It seems like an unnecessary ugliness in code for a temporarily problem, which should be disposed later.

If you need lots of OGL 4.x features, then go ahead and request a 4.x context. If you only need OGL 3.3 plus one or two OGL 4.x extensions, then just query for the extensions that you need and use them rather than requesting a 4.x context. A lot of games request a GL 4.x context and then only use one small OGL 4.x feature.

[smitty3268]

A lot of games request a GL 4.x context and then only use one small OGL 4.x feature.

I'm sure that's true for some games, but others actually do use a number of GL4 extensions. It would be nice to be able to run them on older hardware as well, since it's capable.

[Serafean]

Do you mean initializing an OGL 4.0 context and then utilizing required extensions without fallbacks? (for example TBOs as a fallback for SSBOs absence, etc) It seems like an unnecessary ugliness in code for a temporarily problem, which should be disposed later

Why would you need fallbacks? Just don't work (exit() ) if the required extensions aren't found. It's no different from the current situation...

[bridgman]

The whole point is to get the game working on the 1% Linux user base * 40% preferring the open source drivers supporting random GL4.x extensions. Without fallbacks and early exiting you have just introduced absolutely unnecessary bloat without any money gained from that small segment.

Couple of notes :

1. Rather than supporting "random extensions" the open source drivers try to support "the extensions that apps are actually using", so the fit is often better than expected. There's not 100% alignment, of course, but since a number of the GL 4.x extensions requiring quick-to-implement support were added to simplify porting between DX/OGL there is some natural alignment between "low hanging fruit" and "extensions games use" in addition to explicit developer selection of which extensions to work on next.

2. Since there is a fair amount of code sharing between drivers, when one open source driver picks up support for <extension> the other drivers tend to follow closely behind, so there is a lot more correlation between drivers than you might expect.

Still not sure why you keep mentioning fallbacks. Nobody is suggesting fallbacks, just checking for specific extensions in cases where you only need a subset of a high GL level and failing based on that rather than just saying "GL4.3 or die" if you actually need GL3.3 plus a handful of specific extensions.

[bridgman]

Ahh, OK, you're actually looking for not-yet-unimplemented GL 4.3 features. That explains the "fallback" comments, thanks.

Alex was commenting about a more common case where game code looks for a high GL level and fails, but where the extensions it actually uses are all implemented. In that case faking the GL level with an over-ride will make the game run, but (a) individual users don't like having to do that, (b) we're not yet at the point where those over-rides are being distributed with the games rather than having to be done case-by-case, and (c) if the game code were to check extensions rather than GL level neither (a) nor (b) would be required.

Now that 4.1 is done, I think you'll find the devs will naturally start working on the extensions you want to see, although if compute shaders alone are sufficient to enable some interesting games that one might get worked on sooner... not sure if that is the case though.

[vadix]

Ahh, OK, you're actually looking for not-yet-unimplemented GL 4.3 features. That explains the "fallback" comments, thanks.

Alex was commenting about a more common case where game code looks for a high GL level and fails, but where the extensions it actually uses are all implemented. In that case faking the GL level with an over-ride will make the game run, but (a) individual users don't like having to do that, (b) we're not yet at the point where those over-rides are being distributed with the games rather than having to be done case-by-case, and (c) if the game code were to check extensions rather than GL level neither (a) nor (b) would be required.

Now that 4.1 is done, I think you'll find the devs will naturally start working on the extensions you want to see, although if compute shaders alone are sufficient to enable some interesting games that one might get worked on sooner... not sure if that is the case though.

Hopefully Vulkan extensions will be easier to check for and use. I also hope we don't see people requiring a specific Vulkan version. I know I am guilty of checking for OpenGL 3.1, though everything seems to have that implemented at this point. It is certainly a pain to deal with OpenGL extensions manually.

Maybe Vulkan wont have versions. That would solve the problem.