Better Wine Benchmarking This Summer For Windows Programs On Linux

[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

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

[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

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

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

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

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

[creative]

Michael

I am not sure how far this is in line with the subject, but what about a 64bit virtual drive on PlayOnLinux with the Steam client featuring a Doom 2016 installation? I have it running on my Manjaro 17 XFCE installation drive and it is running pretty good with the Vulkan drivers with Wine 64bit 3.9. While I don't think Doom 2016 has a built in benchmark. One could test the approximate average FPS while standing still in a given area with Dooms built in performance metrics. I am running it on a GTX 1070 and core i7 7700 65watt with 16GB of DDR4 and all is maxed at 1080p. About 175-200fps seems to be what it pulls on average given what area I am in.

[duby229]

Gallium Nine is as native as it gets. Or did someone secretly rewrite it to use Vulkan instead?

You do realize Vulkan is lower level than Gallium right? So VK9 should actually be cl;oser to hardware than Gallium Nine was. And Gallium Nine could actually outperform Windows in many titles!

[VikingGe]

Isn't 50% a bit harsh? I mean that's what you'd expect from DX->OGL, no?

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.

That's exactly the same.

Except that Vulkan is not exactly the same as Gallium. One is an explicit API designed to be used by applications directly, the other is a higher-level, somewhat D3D11-like API designed solely to implement hardware drivers for legacy APIs. Some of the core concepts are fundamentally different:
- Almost entirely static pipeline state (instead of somewhat dynamic state objects)
- Descriptor sets (instead of fixed resource binding slots)
- Render passes (Vulkan-specific)
- Very explicit memory barriers

How much work a Gallium driver needs to do in order to translate that into something the hardware understands obviously depends on the hardware, but with Vulkan you're pretty much guaranteed to do a fair amount of work that's just completely unnecessary in a Gallium-based stack.