RADV+Zink vs. RadeonSI OpenGL Performance On Mesa 23.2-devel

[microcode]

Remember Zink is a gallium3d driver. Also that going to be awhile. There are still GPU being made that don't have the functionality to run vulkan but to have the functionality to implement some amount of opengl. Also there is the case as well on some of these embedded GPU where their vulkan implementation equals zink explosing less opengl than what the native opengl driver can.

That eventually ditching all opengl Gallium3d drivers other than zink that could be a few decades out before that is fully practical. But it also possible that opengl only GPU in embedded usage stay around forever due to cheap licensing.

Zink relies on Gallium3D, and Zink will want to have things to compare to so this probably won't happen like that.

Seems like nobody here reads to the end of something before replying... When it becomes the only "consumer" of Gallium3D, then there will be no need for a separate layer, and the Gallium code can be refactored into Zink, that's what I was saying.
As for "a few decades", Gallium has only existed for like a decade at this point, this isn't a year 2050 thing lol.
As for deficient Vulkan drivers: again, as I mentioned, good GL support could become a matter of providing sufficient extensions in your Vulkan driver, obviously it's possible to fail at that.

Honestly why even bother writing comments here, nobody reads anything except the first line anyway lol.

[smitty3268]

This is a bad presume by you.. One of the 9 different in gl exentions that zink has and radeonsi does not have is linked to how well you can implement tessellation shaders and how tessellation shaders will optimize by a galuim3d driver.

https://registry.khronos.org/OpenGL/extensions/ARB/ARB_fragment_shader_interlock.txt

Yes radeonsi does not have this.

And neither does radv.

RADV as fragment shader interlock under vulkan that zink can use.

No, it doesn't.

smitty3268 this is one of the fun traps of a galluim3d based driver is that back-end not implementing opengl extension can have bigger effects on performance than one would first presume due to the optimization passes and not having feature means the optimization passes do a different code path..

You say all these things as if you are an expert and fully certain, but you're making really basic mistakes and clearly have no idea what you're talking about.

smitty3268 you presumed since Unigine Heaven is 2009 and the missing extentions like ARB_fragment_shader_interlock is 2015 that they don't interact with each other. Problem that is not the case when you are talking about galluim3d based drivers..

If you are going to argue one of those extensions is providing the performance, please prove it.

Should be really easy. Run the benchmark through zink, and then run it again while adding command line arguments to disable the extra extensions in radv.

If there is a performance difference, please post it. I think that would be very interesting. If there's not - and there won't be - please post that as well, along with an apology for wasting everyone's time.

[oiaohm]

If there is a performance difference, please post it. I think that would be very interesting. If there's not - and there won't be - please post that as well, along with an apology for wasting everyone's time.

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1384696-wayland-s-weston-12-alpha-brings-multi-gpu-support-pipewire-backend-tearing-control?p=1389018#post1389018

Please deal with your issue in your post over here. I don't fell like wasting my time on a person who will miss quote and miss attribute so breaking copyright law.

[oiaohm]

When it becomes the only "consumer" of Gallium3D, then there will be no need for a separate layer, and the Gallium code can be refactored into Zink, that's what I was saying.

Yes I did read that.

As for "a few decades", Gallium has only existed for like a decade at this point, this isn't a year 2050 thing lol.

https://www.phoronix.com/news/Intel-Crocus-Default-Gallium3D

June 4, 2013 is the release date of the hardware that supporting yes new driver in 2021. So this says decade old hardware will be supported.

2009 is when Gallium3d appears so just over a decade is correct.

Has there been a new recently made galluim3d hardware driver asahi(Apple M1/M2 SoC) for the yes 2022. So that give you like 2032 if that sticks around for the normal at least a decade of driver support that you see with mesa3d all the time.

Then arm and other GPU used in soc that vulkan implementations don't provide enough functionality to in fact run zink with the same opengl features exposed as their galluim3d drivers..

Next llvmpipe at this stage using zink with lavapipe gives you less opengl functionality and even worse performance than using llvmpipe. Yes getting lavapipe into shape that could take a decade or 2 at the rate lavapipe is developing.

Then you have d3d12, virtgl are also galluim3d drivers. Microsoft could keep d3d12 around for a decade or 2. Virtgl another one that could stick around for quite some time.

It could be a few decades before zink comes the only consumer of Gallium3d. Year 2050 might sound stupid to your but that might be the date when zink comes the only consumer of Gallium3d.

As I said it could be a few decades.
I should have been little more clear on the point zink will come the only consumer of galluim3d:
1) Its not going to be under a decade if there is no abnormal changes due to new galluim3d drivers
https://www.phoronix.com/news/OTgzMg yes mesa normal hardware drivers to be terminated normally have to be over 12 years old.
2) It could be a few decades or more based on how long different drivers have been historically maintained even after they are marked as terminated.
3) could be a few decades or more due to items like virtgl/d3d12 as well.
4) could be a few decades before llvmpipe can be replaced by lavapipe with zink due to lavapipe fairly slow development speed and overhead costs.
5) could be a few decades just based on how old of designs you find in use. 1998 Matrox G200 is still supported by the Linux kernel and it still used in hardware made today. 20-30 year GPU designs still appear in different new soc chips because they are cheap designs to license.

microcode basically there are multi factors here the answer is somewhere between 1 decade and infinity for zink to come the only consumer of galluim3d. The odds would be more few decades. Legacy mesa drivers hang around for quite some time like it or not.

microcode I looked at the complete history of mesa3d this include prior dri1 drivers removal and other things prior to galluim3d to get mesa3d standard operating pattern. I hope you can see now that my possible a few decades is not some random guess that what the history of mesa3d tells you is the most likely time frame for zink to come the only galluim3d driver if everything goes the right ways.

[Linuxxx]

I'm always up for including more benchmarks but limited by the ones that meet my standards around automation/scripting support... I think the only OpenGL games I left out are even older titles or not running on modern distros. If there is any automated-friendly games I missed out on, please let me know.

Here are a few items I just dug up, hope they can be incorporated into your PTS:

1.
Star Swarm is a completely free engine benchmark on Steam, which should work with Proton:

https://store.steampowered.com/app/267130/Star_Swarm_Stress_Test/

2.
Two free Final Fantasy (14 & 15) benchmarks, which should also run flawlessly under Proton:

Final Fantasy 14:

https://download.finalfantasyxiv.com/ys8glaimvmykn88p/ffxiv-endwalker-bench.zip

Final Fantasy 15:

http://gdl.square-enix.com/ffxv/windows/benchmark/ffxvbench_installer.zip

3.
Still remember that "Alien - Isolation" Linux port that you refunded because the built-in benchmark tool wasn't ported over by Feral Interactive?

Well, how about trying the Windows version with Proton?

Should work without problems aswell, according to ProtonDB.

4.
For even more benchmark possibilites, have a look at the following page on PCGamingWiki:

https://www.pcgamingwiki.com/wiki/List_of_games_with_built-in_benchmarks

Really hope at least a few new benchmark test-cases can be added to your excellent Phoronix Test Suite...

Cheers!

[dragorth]

Seems like nobody here reads to the end of something before replying... When it becomes the only "consumer" of Gallium3D, then there will be no need for a separate layer, and the Gallium code can be refactored into Zink, that's what I was saying.
As for "a few decades", Gallium has only existed for like a decade at this point, this isn't a year 2050 thing lol.
As for deficient Vulkan drivers: again, as I mentioned, good GL support could become a matter of providing sufficient extensions in your Vulkan driver, obviously it's possible to fail at that.

Honestly why even bother writing comments here, nobody reads anything except the first line anyway lol.

I did read your whole post and I pointed out why that is a bad idea. I will enumerate so it is explicit.

1. You want separate working drivers to compare your implementation to. That means working gallium drivers for the other GPUs supported by Zink and it means you don't make Zink the only consumer of Gallium combining the 2.

2. Zink relies on Gallium, like all the other drivers. If you integrate Gallium into Zink, and the others are still using Gallium, then Zink is no longer OpenGL on Vulkan, it becomes Gallium, the front end to OpenGL in Mesa.

I will add some just to make it clear.

3. Zink not integrating Gallium means later the next thing that replaces Gallium can be used in its place without having to gut Zink. How do I know there will be a next thing? There always is.

4. Zink can be the test case for the new thing if it isn't tightly coupled to Gallium.

5. Having the other implementations allows Zink to test against known expected behavior, as well as look at more performant implementations. It also gives a default benchmark for Zink to and beat, or at least match.

[Michael]

Here are a few items I just dug up, hope they can be incorporated into your PTS:

1.
Star Swarm is a completely free engine benchmark on Steam, which should work with Proton:

https://store.steampowered.com/app/267130/Star_Swarm_Stress_Test/

Is it just me (or Proton?) or is this benchmark wildly inaccurate? I've been running it in loops on different resolutions/quality settings all day and generally seeing 8~20% variability between runs each time when looking at the same settings between them. Was looking hopeful at first but I have yet to get it running stable at least on Proton Experimental + GNOME Wayland + Radeon.

[smitty3268]

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1384696-wayland-s-weston-12-alpha-brings-multi-gpu-support-pipewire-backend-tearing-control?p=1389018#post1389018

Please deal with your issue in your post over here. I don't fell like wasting my time on a person who will miss quote and miss attribute so breaking copyright law.

Classic misdirection because you're embarrassed at how wrong you were proven in this thread, huh.

It's ok to admit when you're wrong.

Also, I think it's hilarious that you are actually promoting to other people that you think quoting somebody you are replying to here amounts to copyright infringement.

[Linuxxx]

Is it just me (or Proton?) or is this benchmark wildly inaccurate? I've been running it in loops on different resolutions/quality settings all day and generally seeing 8~20% variability between runs each time when looking at the same settings between them. Was looking hopeful at first but I have yet to get it running stable at least on Proton Experimental + GNOME Wayland + Radeon.

I'm sorry to hear that!

Maybe that's intended behavior by the developer, since it's labeled a stress test instead of benchmark.

Meanwhile, I did some more digging, and it turns out that same developer went on to develop "Ashes of the Singularity" on that same engine, which has an actual benchmark mode built-in.

Unfortunately, I don't have that game in my library, however it has a gold rating at ProtonDB, so it could be worth trying that game out within its two hour try-out period on Steam, just to see whether it exhibits the same problem as "Star Swarm":

https://store.steampowered.com/app/507490/Ashes_of_the_Singularity_Escalation/

Also, I'm pretty sure you could get the benchmark mode of "Alien Isolation" easily automated, since the executable contains the "-benchmark" switch/flag.

Plus another game with a gold rating on ProtonDB that also has an explicit "-benchmark" switch/flag is "Anno 1800":

https://store.steampowered.com/app/916440/Anno_1800/

Hope these (and even more games) can be successfully automated...

Cheers and keep up your awesome work!

[marek]

I'm not able to reproduce the Zink score with Heaven. For me, RadeonSI beats it consistently. Below is an FPS chart of every Heaven frame at 1080p.
GPU: Radeon 7600, RadeonSI: 166 FPS, Zink: 150 FPS