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

[phoronix]

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

Now that Vulkan's code licensing issue with Wine has been resolved, the Winevulkan code for supporting Vulkan within Wine to pass onto the host Linux system's Vulkan driver is being updated...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-Vulkan-Preps-1.1

[sdack]

What's the main difference between 1.0 and 1.1 by the way?

I think the only interesting thing is it can handle some DirectX stuff better, which makes it useful to DXVK. Other than that is it just a lot of more special features, or what am I missing?

[VikingGe]

I like this very much, should give me more freedom using Vulkan extensions in DXVK.

sdack A bunch of extensions have been promoted to the core API, including multi-GPU functionality, support for some new SPIR-V functionality etc. I think most of that can be used through extended 1.0 as well so there's probably really not much of a difference in practice.

[sdack]

I like this very much, should give me more freedom using Vulkan extensions in DXVK.

sdack A bunch of extensions have been promoted to the core API, including multi-GPU functionality, support for some new SPIR-V functionality etc. I think most of that can be used through extended 1.0 as well so there's probably really not much of a difference in practice.

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.

Just not what it exactly amounts to. What I do know is that 1.1 can handle structures native to DirectX better, which will benefit DXVK and similar projects obviously. What I don't know is for example what SPIR-V 1.3 makes possible and which software is using it.

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.

[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

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

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

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]

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.

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