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

[marek]

Why though?

Are you compiling your own kernel or is it a distro-provided one?

And yeah, that pretty much explains why RadeonSI is beating Zink on your end, whereas in Michael's benchmarks it's the other way around.

Schedutil is simply a really badly designed CPU governor, unfortunately...

If you can, please re-test with the performance governor on your end, too.

Thanks!

I only build my kernel with "performance" and "schedutil" and the default one is set to "schedutil". I thought it was performance.

[Linuxxx]

My kernel isn't built with any other governor.

Why though?

Are you compiling your own kernel or is it a distro-provided one?

And yeah, that pretty much explains why RadeonSI is beating Zink on your end, whereas in Michael's benchmarks it's the other way around.

Schedutil is simply a really badly designed CPU governor, unfortunately...

If you can, please re-test with the performance governor on your end, too.

Thanks!

[marek]

Are you running the benchmark with the "schedutil" CPU governor on your end?

If so, then that explains why Zink is beating RadeonSI here, because Michael runs all gaming benchmarks with the performance governor, as it should be done.

My kernel isn't built with any other governor.

[Linuxxx]

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

Are you running the benchmark with the "schedutil" CPU governor on your end?

If so, then that explains why Zink is beating RadeonSI here, because Michael runs all gaming benchmarks with the performance governor, as it should be done.

[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

[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!

[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.

[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.

[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.

[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!