More OpenGL Extensions For RadeonSI Are The Latest In A Flurry Of Interesting Activity

[phoronix]

Phoronix: More OpenGL Extensions For RadeonSI Are The Latest In A Flurry Of Interesting Activity

Marek Olšák has continued his busy work on the RadeonSI Gallium3D driver by implementing more extensions and adjusting various limits/constants to match the behavior of their proprietary driver...

http://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-More-Extensions

[boxie]

I for one would welcome a single driver for all of AMD's cards under Linux! With their sole development focus being on a single driver - it can only get better!

[M@yeulC]

Wasn't there some experiments to get Mesa running on Windows at some point?

Also, I wonder if exposing D3D under Linux couldn't give AMD a competitive edge? (Note that I'd prefer Vulkan to become widely adopted instead, but that could be trough DXVK).

[M@GOid]

Wasn't there some experiments to get Mesa running on Windows at some point?

I dunno about that, but Mesa drivers completely stomps OpenGL on the Windows drivers, on games at last. Running American Truck Simulator, Mesa used to outperform the Windows OpenGL (almost double FPS) and be slightly behind DirectX. Now is practically in parity performance.

I couldn't be happier. Too bad that ATS and ETS2 didn't have a built in benchmark tool. It would be embarrassing for the AMD's Windows OpenGL team.

[tildearrow]

Typo:

EXT_disjoint_timery_query

[Brisse]

I dunno about that, but Mesa drivers completely stomps OpenGL on the Windows drivers, on games at last. Running American Truck Simulator, Mesa used to outperform the Windows OpenGL (almost double FPS) and be slightly behind DirectX. Now is practically in parity performance.

I couldn't be happier. Too bad that ATS and ETS2 didn't have a built in benchmark tool. It would be embarrassing for the AMD's Windows OpenGL team.

ETS2 has been stuttering quite badly for me after they reworked the game engine to "help performance on low end systems" a few years ago. Doesn't matter if I run Windows or Debian, and my hardware isn't exactly low end (Ryzen 1700X, 32GiB DDR2400, two R9 Fury's). Game runs like crap either way. I remember it running fine before that update. I haven't touched it in a while though so it might be fixed by now.

[M@GOid]

ETS2 has been stuttering quite badly for me after they reworked the game engine to "help performance on low end systems" a few years ago. Doesn't matter if I run Windows or Debian, and my hardware isn't exactly low end (Ryzen 1700X, 32GiB DDR2400, two R9 Fury's). Game runs like crap either way. I remember it running fine before that update. I haven't touched it in a while though so it might be fixed by now.

It is better now on Windows (i7 3770k/RX 570), I manage to get almost 60 FPS flat on cities, where even Windows was around 30/40. Almost everything on max, less mirror range and AA (that only blur the game for me). I also use 400% rendering for better AA. All that on DirectX, OpenGL is a lost cause on Windows.

Right now Linux, for me, same configs, there is a rectangular artifact on the middle of the screen, from time to time by a fraction of a second, as if it appears when loading or compiling some shader on the fly, as you drive around. It has being like this post Mesa 18.0. Stuttering is almost non existent.

[jf33]

AMD should replace their proprietary OpenGL implementation on Windows with RadeonSI. RadeonSI is just better. It's faster and has less bugs. All OpenGL developers of AMD could join the RadeonSI team. I hope that's the plan.

[Adarion]

Speculation: Maybe AMD sees the good performance of the freedom driver.
So they want to base their blob upon it, in the long term. It should be possible due to the probably mostly BSD/MIT licensing. Then they just add the nasty not-upstreamable bits, blob it and send out the final thing to the workstation people.
One code base, one that seems reliable and performant. Multi-use for standard-Linux, maybe some gaming consoles and workstation blob driver.

But this just me speculating about possibilities.

[bridgman]

It depends on whether the Mesa driver can become a replacement for current OpenGL in the workstation/CAD space - very old apps, heavy use of compatibility profiles, lots of vendor-specific behaviour. If it can then moving to a single OpenGL code base becomes a possibility.

The thing working in our favour is that we have been shipping OpenGL drivers with tight API checkers for a long time now (almost a decade) so a lot of the cases where applications depend on NVidia-specific behavour have been identified. The thing working against us is that in a lot of cases the apps were never fixed and we had to hack similar bugs into our code in order to make the apps run - and some of those were nasty.

If it turns out that Mesa can support all the target apps without having to be hacked in an unacceptable-to-upstream way then this could potentially work.

So they want to base their blob upon it, in the long term. It should be possible due to the probably mostly BSD/MIT licensing. Then they just add the nasty not-upstreamable bits, blob it and send out the final thing to the workstation people.

Depends on whether the nasty not-upstreamable bits can be contained to relatively small areas or whether they end up intertwined with a lot of areas of the driver (in which case maintaining them becomes really expensive and we are better off with two code bases).