Better Wine Benchmarking This Summer For Windows Programs On Linux

[VikingGe]

if you ask Bridgman(AMD) Vulkan is MORE LOW-LEVEL than Galium3D means if you do it right it will run faster than on Galium3D...

You need to stop thinking that having a lower-level abstraction in the middle of the stack is going to give you a magic performance boost out of nowhere. It doesn't.

What you need to understand is that both VK9 and Nine effectively have to do the same thing. Vulkan being lower level just means that VK9 will have to do some work that the Gallium driver is doing for you, and that in turn means that VK9 has to do these things under the restrictions of the Vulkan API. A Gallium driver is not restricted by the Vulkan API, meaning that it can do some things more efficiently if the hardware allows for it.

[duby229]

You need to stop thinking that having a lower-level abstraction in the middle of the stack is going to give you a magic performance boost out of nowhere. It doesn't.

What you need to understand is that both VK9 and Nine effectively have to do the same thing. Vulkan being lower level just means that VK9 will have to do some work that the Gallium driver is doing for you, and that in turn means that VK9 has to do these things under the restrictions of the Vulkan API. A Gallium driver is not restricted by the Vulkan API, meaning that it can do some things more efficiently if the hardware allows for it.

That's not true exactly. You have to look at how those interfaces are made. Gallium was really designed for fixed function hardware, the drivers have to make programmable pipelines look like fixed function pipelines. Believe it that's a much more complicated process that doesn't exist at all in Vulkan, it's a programmable pipeline where fixed function hardware is dealt with in software.

[Weasel]

AFAIK the Gallium3D devs called Vulkan a "Gallium3D 2.0" API so... but I doubt that the developer of VK9 will get to that performance there anytime soon, he still has a lot of stuff left to even implement first, nevermind the performance tweaks...

It would probably be helpful if the Gallium Nine devs contributed to VK9 to speed the development a lot, given their experience with D3D9.

[VikingGe]

Gallium was really designed for fixed function hardware, the drivers have to make programmable pipelines look like fixed function pipelines.

Just look at the documentation. You bind some shaders, set some resources for the shaders to work with, set some pipeline state and execute a draw call. That's basically D3D11 with a few extra functions and struct members here and there. Nine implements all the fixed-function stuff like fog, lighting etc. "in software" (read: pixel shaders) as well, and more recent APIs don't have any of that in the first place.

There's some related cruft in TGSI, but the only thing that radeonsi does with it is assign shader input/output locations, NIR doesn't have that.

[duby229]

It's not a gallium 2.0 by any means. They are totally different types of pipelines... Check this out, maybe this will help...

https://vulkan-tutorial.com/Drawing_a_triangle/Graphics_pipeline_basics/Fixed_functions

[Tomin]

Gallium was really designed for fixed function hardware, the drivers have to make programmable pipelines look like fixed function pipelines.

I'm pretty sure you got that one wrong. Gallium was designed for hardware with programmeable shaders. I think all Gallium drivers support only hardware with Direct3D 9 level (OpenGL 2.0/2.1) functionality IIRC.

[lectrode]

50% is definitely on the lower end, but not unrealistic (take Frostpunk as an example). DXVK isn't necessarily much faster than wine-pba (especially on Nvidia where pba seems to work quite well in general), just happens to work better for a bunch of newer games.

Just a quick FYI for anyone still reading this: in the brief 5-day span between when the quoted remark was made and now, performance improvements specifically affecting Frostpunk were made:

https://github.com/doitsujin/dxvk/commit/f5d73842b296105b4dc6fdb2f114ff57613928a5