Wine Vulkan Preps For v1.1 Support With Licensing Issues Resolved

[VikingGe]

If you wouldn't mind my asking, what specifically in the transition to Vulkan 1.1 is beneficial to DXVK?

It's not so much about Vulkan 1.1 but some of the extensions that wine doesn't currently support, such as VK_EXT_vertex_attribute_divisor which is required to implement D3D11 input fetch rates properly. Wine has been limited to Vulkan 1.0.51 and thus doesn't support any of the new extensions that have been added since then.

Transitioning to 1.1 would be nice to reduce the number of extensions that I have to use and use core functionality instead, but it's not strictly required.

You sir, are shaping up to be a mini Torvalds

This guy is shitting on not one but two projects, without having contributed to either of them and nothing do back himself up, but acting like he knows it all. Can't be arsed to put a polite mask on.

or be man enough to admit the performance of WINE is lacking back to front

So, if you're so confident about winevulkan having a substantial impact on DXVK performance, where are your numbers to prove it?

Why aren't you ranting about wine's implementation of synchronization primitives instead which actually kills performance in certain games?

Nobody needs a DLL on Windows to translate DirectX into Vulkan when you have DirectX.

Nobody is forcing you to use it.

[sdack]

You sir, are shaping up to be a mini Torvalds. Sharp mind and tongue.

No. Torvalds would have written DXVK in C using winegcc and made it a part of WINE from the start and not have written it in C++ and mingw. Nobody needs a DLL on Windows to translate DirectX into Vulkan when you have DirectX.

Now the code first need to be rewritten in C before it can become a part of WINE and none of the divas like this idiot VikingGe here is going to do it of course. He'll be too busy basking in the 3 months of glory he's been mentioned on Phoronix - if he actually is the author. He thinks of others being on a high horse, but then writes C++ code with lambdas while everyone else is writing it in plain C. That's only funny.

[sdack]

Maybe you should get off your high horse. If you can do better than the guy developing winevulkan, or me developing DXVK, go ahead, make it better, but stop bitching around on the forums if all you have to show is a big mouth.

Dude, you can cry a river all you want, but it's not my attitude that's lacking here. Shut your mouth and keep coding, or be man enough to admit the performance of WINE is lacking back to front. Until then are just you the bitch who is unable to see the problems we have. Get your shit together.

[Snaipersky]

Maybe you should get off your high horse. If you can do better than the guy developing winevulkan, or me developing DXVK, go ahead, make it better, but stop bitching around on the forums if all you have to show is a big mouth.

You sir, are shaping up to be a mini Torvalds. Sharp mind and tongue. If you wouldn't mind my asking, what specifically in the transition to Vulkan 1.1 is beneficial to DXVK?

[VikingGe]

You mean you as in yourself, but it is what keeps holding back the performance.

Maybe you should get off your high horse. If you can do better than the guy developing winevulkan, or me developing DXVK, go ahead, make it better, but stop bitching around on the forums if all you have to show is a big mouth.

[sdack]

No matter what you can't go directly to Linux libvulkan.so.1 due to win32 integration needs ...

You mean you as in yourself, but it is what keeps holding back the performance.

[Thunderbird]

It's not worth it for now while the various projects are still developing and each in their own way, but eventually will we see someone who will merge the efforts and cut out unnecessary layers.

And how would it make a project more sensitive to a specific wine version than they already are when you remove a layer? Only if you're stupid really.

ssorgatem Sorry, I don't care for who is who on the Internet. Nor should you.

As I said wine-vulkan itself has little overhead. However if you want to cut out unneeded calling convention conversions (if you compiled dxvk natively for Linux), then an option is to use the Wine internal API to access essentially winex11.drv or other Wine graphics drivers directly, so skipping vulkan-1.dll. This is not an approach I recommend as when Wine data structures change (e.g. between Wine versions) because we add more vulkan APIs, DXVK may break or need a recompile. No matter what you can't go directly to Linux libvulkan.so.1 due to win32 integration needs, which are managed by wine's graphic drivers.

[sdack]

wine-vulkan has very low overhead. Yes it is an extra layer, but a thin one dealing with calling extension conversion and integration with win32. I have never benchmarked the overhead, but probably < 0.1%. Technically it is possible to avoid that overhead a bit by loading wine's vulkan in a different way similar to how vkd3d does it, but it is not worth the effort and makes dxvk sensitive to specific wine versions.

It's not worth it for now while the various projects are still developing and each in their own way, but eventually will we see someone who will merge the efforts and cut out unnecessary layers.

And how would it make a project more sensitive to a specific wine version than they already are when you remove a layer? Only if you're stupid really.

ssorgatem Sorry, I don't care for who is who on the Internet. Nor should you.

[Thunderbird]

Also how much is lost due to DXVK using wine-vulkan instead of using the Linux Vulkan API directly? Those are the really interesting questions. That 1.1 is more than 1.0 or that WINE devs will be implementing it was pretty obvious when one has followed the trouble with the license.

wine-vulkan has very low overhead. Yes it is an extra layer, but a thin one dealing with calling extension conversion and integration with win32. I have never benchmarked the overhead, but probably < 0.1%. Technically it is possible to avoid that overhead a bit by loading wine's vulkan in a different way similar to how vkd3d does it, but it is not worth the effort and makes dxvk sensitive to specific wine versions.

[ssorgatem]

Sure, the DXVK author already said he will use 1.1 as soon as it becomes available. And having "a bunch of extension" is obvious.

sdack .... @VikingGe is the DXVK author xD