Questions about licensing issues, filtering extensions vs wine staging vulkan support..

[oscarbg]

Hi, just seeing how you filter extensions, in a case by case basis, have some questions: 1) you mention licensing issues for 1.0.51 only level or some filtering of exts if I undertand correctly.. can you clarify what's the problem? is some license change in Khronos headers since 1.0.51.. has Khronos provided an ETA on resolving this issue.. seems Vulkan Next (2?) may be announced at GDC by Khronos with even more extensions and keeping at 1.0.51+ext filtering could be seen as even more limiting (altough I know no games will be using for a while...) 2) just seeing Wine Staging Vulkan support altough "technically" inferior (vulkaninfo doesn't work,etc..) it exposes all device extensions AFAIK.. as for example you mentioned it would be tricky to support maintenace2 ext and they expose it.. has Staging Vulkan the same issues as yours but anyway they expose the extension? i.e. programs using it, can run into problems? (I doubt it as DXVK seems make use of maintenace2 for ex. from logs when using Wine Staging +DXVK and doesn't seem to work bad).. or is that, due to implementation differences (perhaps more direct passthrough of calls,don't know) they are free of issues and all extensions work even if they add new functions (API calls) or new structs.. just asking, pure curiosity..

[roderickc]

The licensing issue is that Vulkan after 1.0.51 is Apache licensed including 'vk.xml' from which code is generated. This makes generated code a derived work and licensed under Apache, which is tricky to combine in the Wine source tree as Wine is LGPL 2.0. I have been working with Khronos for a few months to resolve this, but it is a long process.

Also be aware that wine-staging is at Vulkan 1.0.33 or somewhere near there. They are not doing the right amount of filtering and if unlucky things will just crash. Check my wine-vulkan code and you see many 'convert_vk..' functions to convert structures, because of alignment issues on 32-bit windows (64-bit is fine). Many of the new extensions do need the conversion and staging is incorrectly reporting them and on 32-bit things will just crash.

[oscarbg]

Ok.. thanks for clarification.. didn't know Wine Staging was even an older version.. some things to say then: ok you mention: "issues on 32-bit windows (64-bit is fine)" well.. why then you also do extension filtering on 64bit bit winevulkan library also.. as far as I remember I did run vulkaninfo utility both 32bit and 64 bit Windows executables and extensions exposed were the same.. shouldn't expose 64bit version all extensions that don't need any convert_vk functions..

I'm not a lawyer and know it's not the first priority, but altough you can't merge on Wine support for >1.0.51 doesn't preclude from having posted some say "unofficial" patches for people to try on his own, right? I mean similar to Mesa support for S3TC until patents expired should be build by the user distros couldn't ship it, right?..

[roderickc]

At some point if it really came to it, I may provide unofficial patches here. I just hope it won't get there as extensions are quite some work (not all are simple passthrough). Right now the main priority is to get all my work into Wine, which is still quite some work.

[oscarbg]

you are of course right.. great work by the way!! still don't catch why for 64bit conversions are needed or is due to changes in ILP model in Windows vs Linux ( I mean sizes of integer,long or pointer change between Win64 and Linux64 on x86 PCs?)

[roderickc]

For 64-bit no conversions are needed. It is for 32-bit, but don't want to add any nasty hacks. In addition we can't blindly pass extensions through as some require callbacks. Callbacks are painful, because of calling convention differences between win32 and linux.

[ssorgatem]

I'm curious... where exactly is the problem between the Apache license and wine's LGPL? Isn't the Apache license more permissive?

I mean, LibreOffice (LGPL) have been incorporating changes and code by Apache OpenOffice (Apache) without trouble... it's just the other way around (LGPL>Apache) that's not possible.

So going from vk.xml (Apache) to wine-vulkan (LGPL) should be possible, right?

What's more, the Apache license explicitly allows the redistribution of derived works under a different license provided its own requirements are still met (which theya re with the LGPL):

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

[roderickc]

There are various interpretations of the Apache license. The most conservative readings as followed by FSF / GNU is that Apache 2.0 and LGPL v2.0/2.1 are incompatible mostly due to patent clauses. However it is compatible with LGPL v3.

We are working with Khronos legal, but it is just a slow process, because they have to be quite careful. From an engineering perspective I would like to take the 'APIs are fair use' kind of approach, but we want to be careful.

[roderickc]

We resolved the licensing situation recently after many months of negotiation.

[Kerrung]

@roderickc, thank you very much! Tell me, please, when you make a pull request to add Wine Vulkan 1.1 to Wine upstream? https://source.winehq.org/patches/

[roderickc]

I already pushed code to wine-vulkan a while ago for vulkan updates. It still needs some more work, but likely in the coming weeks I will have time to clean things up and upstream it. To be safe in the next month or so it will be in. I will sync my wine-vulkan branch with upstream Wine shortly.

[Kerrung]

@roderickc, Thank you so much!