Considering DXVK works on wine-vulkan (which the patches are based on, same dev), there should be no issue with Wine master once it is released.

Support and support... I am using wine-vulkan from his git, and the wine version is "dev" ie. wine-dev-3.2. This seems to work on vulkan things as suspected, with "proper" support for vulkan ICD loaders and stuff.

You can test this out with vulkanCapsViewer http://vulkan.gpuinfo.org/download.php This gets a few errors if using wine-staging-2.21, but no errors with wine-vulkan..

Another program to test vulkan demo stuff (that does not work with wine-staging-2.21) is http://www.ozone3d.net/gpu_caps_viewer/ . Now this will not list vulkan support on the mainpage, but the various vulkan tests will run, as it relies on the vulkan ICD loader supported by wine-vulkan.

Nuff promoting i guess... I am still struggling with some weirdness when using dxvk with the colors. Fingers have ofc been pointed to my setup, as others seem to run fine... so there must be something wrong with my dxvk compile :) Anyway.. wine-vulkan works with vulkan support as far as wine running the windows program :)

that does not work with wine-staging-2.21

This gets a few errors if using wine-staging-2.21

For those wondering:

fixme:vulkan:vkGetInstanceProcAddr missing function "vkGetPhysicalDeviceFeatures2KHR"
fixme:vulkan:vkGetInstanceProcAddr missing function "vkGetPhysicalDeviceProperties2KHR"

Vulkan Hardware Capability Viewer
Changelog
1.4 - 2017-05-28

• Added support for new features and properties provided via VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2

@pchome Sorry for that.. Must have been a few versions ago i tested gpu caps viewer with wine-staging, but i see that its working, and vulkan tests are running.

So.. you are saying winehq should rather opt to include wine-staging's version of vulkan than the wine-vulkan implementation? I kinda thought the wine-staging way of implementing vulkan was a bit "hack'ish" in the way that it was not implemented correctly enough for winehq-dev.. cos they hate everything that is not "by the book" and pass all the tests :)

You are ofc welcome to put up patches to winehq to get them included in wine if you feel the staging route is the best way to go :)

Wine upstream won't include Wine staging Vulkan patches, that's rather clear.

@shmerl Kinda what i thought too, and seeing as wine-vulkan has a more "correct" way of implementing it, it atleast seemed more of a chance :)

So what does it mean "dxvk supports wine-staging or wine-vulkan"?

@doitsujin Can you include vulkan patches from wine-staging as an option in DXVK?
If so I can create PR. I have some code already I'm using to build vulkan dlls for wine-3.2 and created dlls works w/a issues so far.

https://github.com/pchome/dxvk/tree/winebuild/external/vulkan
To fetch some required wine files use sh vulkan-init.sh once.

@pchome Why?
Why would DXVK have vulkan-patches for wine? Those are two projects, and i don't really see other than @doitsujin is right in saying what he does. Ain't DXVK also possible to use in Windows as a DX11 -> Vulkan thing? Its not ONLY for wine tho is it?
I dont really see the point in having one semi-unrelated thing @doitsujin have to keep updated/fixed/rebased to work with wine-versionX.

Sorry if i have missed this totally, but my understanding of DXVK project is that it is a translation layer for DX11 -> Vulkan. That it is "of best use" for Linux users running wine is one thing, but if the code is optimized enough eventually, one might actually want to use this in Windows aswell and gain something either performance or less cpu usage in Windows.

What COULD be done ofc is putting up a link to the various wine git's on DXVK's WIKI "For Linux/wine users" kind of thing, but imo it should not be included in the project. Not my call tho :)

@SveSop

Why?

Why not? Many projects includes external dependencies. If you have an dependency installed - ok, otherwise included sources can be used.

I dont really see the point in having one semi-unrelated thing @doitsujin have to keep updated/fixed/rebased to work with wine-versionX.

Those patches from staging don't dependent on wine version. There are two directories only and only wine dependency is wine/libs/port and related wine/includes which don't installed with wine but used for it's build. So no need to support/rebase/fix and can be used w/ any wine version (even git master).

But due to it's hack'ish implementation it can be easily extended by adding definitions to .spec and headers (or so). For example w/ two missing *2KHR functions mentioned above.

So why not to have this option even if it only for two of us.

@doitsujin

I'd like to ask the same thing, why would we have to build and ship Vulkan libraries (the wine-staging ones at that, which are not exactly great)?

• like example
• for testing
• when no other vulkan implementation available
• ...

@pchome

1. Who will maintain the staging-vulkan patches/source?
2. Is it needed to do work to get staging-vulkan to auto-compile in a easy manner with DXVK meson build?
3. If the answer to question 2 is yes: Who will do that work, and is it time well spent over further optimizing DXVK code?
4. What happens to the staging-vulkan dependencies if wine-vulkan gets accepted to master? Easy to add, easy to remove?
5. Does the discussion "staging-vulkan is better than wine-vulkan" really belong at the winehq board rather than trying to get something implemented that MAY be in wine-master in possibly near future?

The only upside would ofc be to test implementation of new extensions and vulkan functions faster than waiting for wineHQ to accept patches... but would not staging-vulkan break vulkan in wine if wine-vulkan patchset gets accepted?

Again, not for me to decide, but perhaps TODAY is not the time to implement this, and rather wait to see if wine-vulkan gets rejected, and THEN propose this as an alternative? :)

@SveSop

Does the discussion "staging-vulkan is better than wine-vulkan" really belong at the winehq board rather than trying to get something implemented that MAY be in wine-master in possibly near future?

It's not discussion but question "Can you?" and "Can I help?". And not about "better" but "easy to try dxvk with your current wine".

For now you need to get gslang, mingw32, wine-staging or wine-vulkan or wine-git (in future), maybe spirv-tools, apitrace, what I forgot to mention?. Even me using Gentoo confused a bit. You can try to collect all this tools and "pray" everything will be built/installed/work in your [disro name] with your [wine version].

But I have luck to build dxvk on Linux w/o mingw32 and vulkan dlls w/o wine-staging. Also experimented w/ code by including spirv validator and optimizer to check generated code on the fly which can be useful too for logging more data w/o repeatedly do legalize trick. And can use ANY wine version to try DXVK. Everything was somehow combined, "optioned" and published. And if it can be useful for DXVK and it's users - welcome, if not - who cares.

@pchome

1. If you ask any questions about wine-staging TODAY on the WineHQ sites (on the forums) you will most of the times just be told off with "try with latest wine-dev", because officially wine-staging is dead. (Yeah, some have started the work to rebase the patches, but so far not finished). So, basically wine-staging is "non-supported" as of wine-3.0 it seems.
2. Its not a question of if it is nice and welcome addition to help ppl out with their DXVK testing.. The question is if its the right thing to do, to implement this into DXVK.

Having bits and pieces helping people out is great! Having a stand-alone vulkan loader that works with any wine is great! Having it included to the DXVK project with the extra management?

WineHQ dev's is also working on the VKD3D project to get DX12 -> Vulkan layer, and if DXVK gets good enough eventually, suddenly there could be both DX11+DX12 support via Vulkan. That i think should be something to aim for. For now the best bet to get Vulkan implemented in Wine is wine-vulkan, as staging-vulkan is a "rejected" project AND a "dead" project, unless ofc you can get the patches accepted by wine :)

This project will take some additional time to mature. As it does, it is quite probable the wine-vulkan patches will get mainlined too. In the meantime, people will have to jump through hoops to get it working, but that might even be a good thing, as it means a reasonable amount of issue tracker activity, and from people willing/able to setup their installations enough to use dxvk.

wine-vulkan patchset has been assigned to Józef Kucia for review it seems, so lets see what comes from that :)

Some progress, the patches are almost there.

Committed to git.
https://source.winehq.org/git/wine.git/commit/fcc7af83229ee46a177311a658b7ec92ee4d8d50

@SveSop only stub though

Was more than that tho, i just pasted the commit to the first one.

> 27 hours ago 	Roderick Colenbrander	winex11: Implement vkEnumerateInstanceExtensionProperties. 	commit | commitdiff | tree
> 27 hours ago 	Roderick Colenbrander	winex11: Add Vulkan stubs. 	commit | commitdiff | tree
> 27 hours ago 	Roderick Colenbrander	winevulkan: Define vulkan driver interface. 	commit | commitdiff | tree
> 27 hours ago 	Roderick Colenbrander	winevulkan: Implement global Vulkan function stubs... 	commit | commitdiff | tree
> 27 hours ago 	Roderick Colenbrander	winevulkan: Implement vk_icdNegotiateICDInterfaceVersion. 	commit | commitdiff | tree
> 27 hours ago 	Roderick Colenbrander	winevulkan: Add stub ICD. 	commit | commitdiff | tree
> 27 hours ago 	Roderick Colenbrander	winevulkan: Add initial Wine vulkan header. 	commit | commitdiff | tree

Haven't tested any compile or if it is a "complete set" working, but atleast stuff is happening :)

So are current patches good or not enough yet? I'm interested in giving a try to dxvk, but I'd like to work with upstream code.

wine-vulkan git is now up-to-date with wine-3.3... but yes, its not in "mainline" yet tho, but i have no doubt it will be :)

From @roderickc:

Roughly half of my patches are in main Wine, it will probably take until Wine 3.5 or maybe Wine 3.4 if things go well this week for the bulk to be integrated.

https://www.winehq.org/pipermail/wine-devel/2018-March/124262.html

This wave of patches gets winevulkan to a usable state. Many simple
applications such as Doom, Wolfenstein II and many others including
dxvk should now work.

Use of winevulkan at this point requires installation of Windows Vulkan
SDK e.g. through winetricks (latest version). In addition registry settings
and winevulkan.json need to be added by hand, which will be improved in
the future.

Let's see if they get merged for 3.4...

Let's see if they get merged for 3.4...

... tomorrow (if my calculations are correct)

wine master with dxvk, using the last set of pending Vulkan patches (applied manually):

So, basically it's ready.

@doitsujin: And, it's landed now. You can update the front page to mention wine-master.

Apparently, though there is some major problem with supporting Vulkan higher than 1.0.51. According to @roderickc, they changed the license from BSD to Apache for the API after 1.0.51, and Apache is incompatible with LGPLv2 of Wine. That's really a mess since it won't allow using any newer Vulkan features.

The thing is, LGPLv2 is incompatible with Apache (you can't include LGPLv2 code into an Apache project)... but that's not true the other way around.

LibreOffice, for example, has extensively taken Apache code from Apache OpenOffice and incorporated it into its own LGPLv2 codebase.

I did a bit of digging in Khronos repo:

According to github:

Up until 1.0.8.1: MIT-style license
From 1.0.11.0 and on: Apache-style license

So I have no idea where 1.0.51 is coming from. And yes, I've read that it should be one way, but it seems to be more complicated than that:
https://www.apache.org/licenses/GPL-compatibility.html

Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work.

So, if this restriction is on the (L)GPL side, simple permission from Wine owners would resolve all this.
@roderickc: did you ask Wine copyright holders about this?

The text you quote is about the GPL licence, not the LGPL which is the one used by wine, and which is compatible with the Apache license, unlike the GPL.

LGPL still might have the problem of patents clauses like above. Let me find another page explicitly about LGPL.

https://opensource.stackexchange.com/questions/5664/linking-from-lgpl-2-1-software-to-apache-2-0-library

But again, I don't think it can't be resolved with explicit permission from Wine developers (since they are copyright holders), but it does pose some complication for them.

Not having delved much into the world of licensing, i wonder a couple of things.

1. Having a "finished" binary compiled under eg. LGPL, means that all libraries involved in the compile has to be LGPL or "compatible" with that license.. right?
2. If i personally take a LGPL licensed source, and add whatever non-free crap i want MYSELF, it is my own problem.. and the creators of said free source based on LGPL is still "ok".. right?
3. Would it be possible to make the >1.0.51.0 vulkan libraries be a "if you want newer, you have to compile yourself" kind of deal? Ie. some sort of modular "download this xml and library, and compile" kind of thing for those wanting that, and thus no blame on the wine source license?

Stupid questions i guess, and i have a sneaky suspicion that the answer to all 3 questions is "yes" :)

I'm not a lawyer, but the way I see it:

1. Yes, anything compiled into LGPL binary should be LGPL compatible.
2. When you are the owner, then I think it's up to you to enforce that comatibility, and if you explicitly don't care about such detail than no one has a problem. The other way around should be upheld though. I.e. when you combine anything with your code, that anything should consider your code compatible with itself. Which is OK in this case (Apache view LGPL as compatible with their license).
3. I suppose that's always an option.

Or, i guess Codeweavers could have "Crossover 18 - Supporting Vulkan 1.1.70.1" on their next release?

We can open a bug for them, the problem is that making such permission can create some complicated legal mess for them. I.e. they won't be able to say "our code is LGPLv2" anymore. They'll have to say "our code is LGPLv2 plus a whole mess of who knows what". That creates ambiguity for their codebase, especially for anything that's derived from Wine itself, and may be that's not what they want to do.

That said, having a separate branch just for that sounds like a good workaround, but it creates an extra burden to maintain it again.

I guess making such permissions would create problems.. however, is it a problem for Codeweavers and/or WineHQ that places such as this, or "staging" to provide scripts/patches that make this possible?

Could i get in some sort of legal battle if i create a git that has a patch that enables you to run a script that downloads whatever vulkan version and you have to compile it? Hmm...

If you apply patches and compile yourself - it shouldn't be a problem in general.

I just want to highlight that I have been working on this with Khronos for quite some time. The discussions are progressing nicely and they really want to find a solution, but it is just a slow process because of legal reasons. We will keep discussing in the background and hopefully reach a resolution soon.

Just tested wine-master. It works, so now what's left is to update the documentation (wine 3.4 is already good too). It's probably also good to include details about installing Vulkan SDK in the prefix, since there won't be a separate wine-vulkan repo page.