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

[QwertyChouskie]

I'm a little confused why Zink ever outperforms a native driver. With DXVK it was a little more obvious because it would basically make things multi-threaded, but Mesa can be multi-threaded, so where's the performance boost coming from?

Likely at least part of it is taking advantage of ACO rather than the LLVM-based shader compiler. Once RadeonSI uses ACO for all shader types, it will almost certainly perform better.

[spheenik]

Very nice effort, and once this goes a bit further, vendors will probably start to build this into their GPU drivers instead of opting for building a whole OpenGL stack for themselves.

[smitty3268]

Some of it is simple enough.

Go down to "Extensions that are not part of any OpenGL or OpenGL ES version" and notice that Zink has 9 more optional opengl extensions than radeonSI has. Zink is the most complete opengl implementation mesa3d has. So zink can allow programs to go code paths they would not be able to when using radeonSI and those code paths can be better performing.

Yes there is still 9 more extensions documented Khronos Group that Zink does not have yet.
57 extensions at Khronos
48 extension by zink.
39 extensions by radeonSI

The 9 difference between zink and radeonSi those 9 exist as implemented with Intel/Nvidia/Qualcomm drivers of course as random-ally spread.. So programs have code paths for when they have intel/Nvidia/qualcomm that cannot run with radeonSi because opengl extension does not exist but when you use Zink can run.

Zink is not outperforming radeonsi in Unigine Heaven because it implements more GL extensions.

[smitty3268]

I'm a little confused why Zink ever outperforms a native driver. With DXVK it was a little more obvious because it would basically make things multi-threaded, but Mesa can be multi-threaded, so where's the performance boost coming from?

As I recall, Unigine Heaven in particular was extremely heavy on tessellation shader use, and I believe radeonsi always ran slow on it compared to their windows driver. I suspect something in radeonsi for tess shaders just isn't programmed optimally, and the vulkan drivers probably optimize it better. Whether that's ACO vs LLVM or what, I'm not sure.

[oiaohm]

Zink is not outperforming radeonsi in Unigine Heaven because it implements more GL extensions.

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.

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

Yes part of the performance difference with Unigine Heaven is a missing opengl extension. Remember of a opengl extension has not be implemented radeonsi backend in the auto optimization of galluim3d will not be using that feature either.

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

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

[Michael]

SuperTuxKart is quite automation-friendly. Everything can be set via command-line flags. There should even be a PTS profile for it, but it may need to be updated to the latest version of STK (1.4).

SuperTuxKart regressed upstream, unfortunately... Last attempt I wasn't able to workaround it, but basically vsync mode ended up getting forced on when in the profiling/benchmark mode and the developer who made the test profile previously is no longer working on it I believe he said.

[Gusar]

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

Check again. It does not. It's still in development: https://gitlab.freedesktop.org/mesa/...requests/22250

I also can't find any info that Unigine Heaven uses interlock. The main user of interlock are emulators, which use it to emulate non-standard fixed function blend engines that consoles have. Some Switch games also use it for blending and then two or three PC games.

[oiaohm]

I also can't find any info that Unigine Heaven uses interlock.

Translation layers over Vulkan or OpenGL:
DXVK (Direct3D 11.3);
VKD3D (Direct3D 12) — requires this extension to advertise feature level 12_1 support;
Ryujinx (Nintendo Switch);
Zink (OpenGL);
This is noted for a reason.

Gusar this is the catch here. The main user is not the only user. DirectX 11 and 12 there are a lot of different games that use it. Intel when they implemented interlock in galluim3d for opengl also used internally with galluim3d in optimization passes..

So this is a case the game it self does not have to use it. Optimization pass on shaders can use it if the feature is enabled. There is one feature on the Nvidia open source Nvidia driver that AMD does not have that also is used in galluim3d shader optimization passes.

Gusar the catch here is Zink uses the shared optimization passes of galluim3d. Over the years different opengl hardware vendors have implemented support for many different optimizations inside galluim3d if the device part of galluim3d reports feature exists. The opengl extension is basically tip of iceberg that shows up if that feature is in the device layer but its not only used to say expose X opengl feature it also uses to say to optimizer inside gallim3d drivers you can use this feature in upper optimization passes.

Zink enabling more opengl extention basically make a collage of all the different opengl vendors upper level optimization code in galluim3d. This effect is only there because Zink extra 9 extensions over AMD may not have been implemented by AMD but have been implemented by some other vendor and then intergrated.

Gusar its really simple to look at game and say game does not call that feature its never used so totally forget opengl/dxvk/vkd3d/.. is a translation layer that internally has it own optimizer and that can select to use features that the application does not when it decides it suitable.

DXVK also optimizes differently with direct X 11 applications when it has interlock and when it does not even if the direct x 11 application is not 11.3.

I though that patch had gone in on the RADV side.

Gusar there are three questions.
1) what features the application users.
2) what features the translation layer the application uses can it use.
These two questions get you so far list of support opengl extensions with opengl drivers answers 2 to a point..
3) what features the translation layer will use without the applications knowledge or requested to use possible to improve performance in optimization passes.
Yes the third question is the bit you overlooked the indirect usage.

The third bit is why at for a long time mesa3d you would see new extension added to a mesa3d driver resulting in glgears and the liking increase in performance when application never used those opengl extensions directly. Fun of indirect usage. The indirect usage in galluim3d can explain at times zink higher performance not all the time of course.

ACO vs LLVM is another part of it with the AMDGPU driver. RADV using ACO backend and radeonsi using the llvm backend at this stage by default again difference in optimization passes.

[rmfx]

Sometimes RadeonSI wins, sometimes Zink wins…
the reason: none of them is perfect.

If RadeonSI had ten extra years of active optimization dev added to the current driver, it would win by far, and the exact same for Zink if it had these 10 extra years of active dev.

The full potential of hardware is never truly reached.

That’s why imho dev attention should start shifting toward Zink because it’s more universal and future proof than RadeonSI and if all gl efforts where combined into Zink optimization, code refactoring, compliance, and feature additions, there would be no need for duplicated work.

[Gusar]

So you're saying Zink will inject interlock when translating GL to Vulkan, even if the original GL code did not use it. Can you point to the part of the Zink code where that can be verified? And even if yes, do you know for sure that's the case when running Heaven via Zink?

Also, you glossed over the part where RADV in fact does not have interlock (I seriously doubt Michael patched mesa with the in-progress work I linked to). So even if Zink injects interlock when used with an appropriate driver, RADV is currently not such a driver.