Hi all,
Now that we have an initial Vulkan ICD, the question is how do we supply users with the Vulkan loader (vulkan-1.dll). At the moment users need to install it themselves by downloading Vulkan SDK e.g. through winetricks or lunarg website.
There are a various options each with their pros and cons.
1. Use the official Vulkan loader and bundle it with Wine. The vulkan loader is open source and could thus be bundled. However last year the license switched from BSD to Apache. At some point I compiled the loader using winegcc though had to make a few code changes, which I'm sure could be upstreamed to Khronos.
2. Provide our own minimal vulkan-1.dll implementation. It would cut some corners by not supporting layers or handling of multiple ICDs, which is were most of the complexity lays. In terms of loading order we would prefer native over builtin as e.g. Steam may want to use the real loader to provide layers such as overlay. Last summer I did create such a loader, but I would need to dust it off. Most of the code is very easy to generate and would most can share some code with winevulkan e.g. dispatch structures and macros.
3. Provide vulkan loader in a wine-gecko/wine-mono kind of way through an external download. Not as user friendly and not sure how desired for Wine unit tests needing an external dependency.
In an ideal world, I would prefer option 1) as it doesn't make sense to duplicate work and it also provides the most features. However, the question is whether we would want Apache 2.0 licensed code in Wine. Technically we are LGPL >= 2.1, so under 3.0 license this would be compatible (and you could offer an option to not build the dll maybe).
More realistically I suppose 2) is the preferred method for now. Thoughts?
Thanks, Roderick
Missatge de Roderick Colenbrander thunderbird2k@gmail.com del dia ds., 17 de març 2018 a les 12:39:
- Use the official Vulkan loader and bundle it with Wine. The vulkan
loader is open source and could thus be bundled. However last year the license switched from BSD to Apache. At some point I compiled the loader using winegcc though had to make a few code changes, which I'm sure could be upstreamed to Khronos.
Thanks for working on this! I don't know what the right solution is, but just so you know: You'd also have to convert the // comments in the loader code to /* */ comments because of the large number of compiler versions Wine tries to support.
-Alex
On Sat, Mar 17, 2018 at 7:39 PM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
Now that we have an initial Vulkan ICD, the question is how do we supply users with the Vulkan loader (vulkan-1.dll). At the moment users need to install it themselves by downloading Vulkan SDK e.g. through winetricks or lunarg website.
There are a various options each with their pros and cons.
- Use the official Vulkan loader and bundle it with Wine. The vulkan
loader is open source and could thus be bundled. However last year the license switched from BSD to Apache. At some point I compiled the loader using winegcc though had to make a few code changes, which I'm sure could be upstreamed to Khronos.
- Provide our own minimal vulkan-1.dll implementation. It would cut
some corners by not supporting layers or handling of multiple ICDs, which is were most of the complexity lays. In terms of loading order we would prefer native over builtin as e.g. Steam may want to use the real loader to provide layers such as overlay. Last summer I did create such a loader, but I would need to dust it off. Most of the code is very easy to generate and would most can share some code with winevulkan e.g. dispatch structures and macros.
- Provide vulkan loader in a wine-gecko/wine-mono kind of way through
an external download. Not as user friendly and not sure how desired for Wine unit tests needing an external dependency.
In an ideal world, I would prefer option 1) as it doesn't make sense to duplicate work and it also provides the most features. However, the question is whether we would want Apache 2.0 licensed code in Wine. Technically we are LGPL >= 2.1, so under 3.0 license this would be compatible (and you could offer an option to not build the dll maybe).
More realistically I suppose 2) is the preferred method for now. Thoughts?
I agree that 2) is the preferred method. Our vulkan-1.dll can be really minimal so it won't duplicate what the official Vulkan loader does. We don't really need a dispatch table per object since winevulkan.dll always provides the same function pointers for all dispatchable objects. We need to simply forward to winevulkan.dll and export the same functions as the official Vulkan loader. Dispatch tables are only needed when multiple ICDs and/or Vulkan layers are involved.
I think that our minimal vulkan-1.dll is a good option because: * It should be really little of code. * It still allows installing the official Vulkan loader, which can be preferred in rather rare cases. * We still may provide the official Vulkan loader as an optional installable addon in the future. * It's good for users. Basically, everything excepts Vulkan layers is expected to work in Wine out of the box with our minimal vulkan-1.dll. No need to install or configure anything to get Vulkan working. * It doesn't involve licensing issues. * It doesn't involve importing ~15k SLOC into the Wine source tree.
Józef
On Wed, Mar 21, 2018 at 10:36 AM, Józef Kucia joseph.kucia@gmail.com wrote:
On Sat, Mar 17, 2018 at 7:39 PM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
Now that we have an initial Vulkan ICD, the question is how do we supply users with the Vulkan loader (vulkan-1.dll). At the moment users need to install it themselves by downloading Vulkan SDK e.g. through winetricks or lunarg website.
There are a various options each with their pros and cons.
- Use the official Vulkan loader and bundle it with Wine. The vulkan
loader is open source and could thus be bundled. However last year the license switched from BSD to Apache. At some point I compiled the loader using winegcc though had to make a few code changes, which I'm sure could be upstreamed to Khronos.
- Provide our own minimal vulkan-1.dll implementation. It would cut
some corners by not supporting layers or handling of multiple ICDs, which is were most of the complexity lays. In terms of loading order we would prefer native over builtin as e.g. Steam may want to use the real loader to provide layers such as overlay. Last summer I did create such a loader, but I would need to dust it off. Most of the code is very easy to generate and would most can share some code with winevulkan e.g. dispatch structures and macros.
- Provide vulkan loader in a wine-gecko/wine-mono kind of way through
an external download. Not as user friendly and not sure how desired for Wine unit tests needing an external dependency.
In an ideal world, I would prefer option 1) as it doesn't make sense to duplicate work and it also provides the most features. However, the question is whether we would want Apache 2.0 licensed code in Wine. Technically we are LGPL >= 2.1, so under 3.0 license this would be compatible (and you could offer an option to not build the dll maybe).
More realistically I suppose 2) is the preferred method for now. Thoughts?
I agree that 2) is the preferred method. Our vulkan-1.dll can be really minimal so it won't duplicate what the official Vulkan loader does. We don't really need a dispatch table per object since winevulkan.dll always provides the same function pointers for all dispatchable objects. We need to simply forward to winevulkan.dll and export the same functions as the official Vulkan loader. Dispatch tables are only needed when multiple ICDs and/or Vulkan layers are involved.
I think that our minimal vulkan-1.dll is a good option because:
- It should be really little of code.
- It still allows installing the official Vulkan loader, which can be
preferred in rather rare cases.
- We still may provide the official Vulkan loader as an optional
installable addon in the future.
- It's good for users. Basically, everything excepts Vulkan layers is
expected to work in Wine out of the box with our minimal vulkan-1.dll. No need to install or configure anything to get Vulkan working.
- It doesn't involve licensing issues.
- It doesn't involve importing ~15k SLOC into the Wine source tree.
Józef
I agree as well a minimal vulkan-1 is at least short-term the best and easiest for our users.
As you said as well dispatch tables are not needed. Though they could be handy just to allow a tiny bit of code sharing. E.g. moving struct vulkan_instance_funcs/vulkan_device_funcs and related macros to a common place (e.g. vulkan.h or a new header vulkan_icd.h). Sharing is probably not really worth the effort as thunks become slightly messier (need to deference the first magic pointer).
A real shortcut I'm almost considering taking is to have vkGetInstanceProcAddr / vkGetDeviceProcAddr maybe directly use the ICD and avoid an unneeded vulkan-1 thunk and the need for a full implementation in vulkan-1 of the lookup stuff. Also avoids having to duplicate the Doom/Wolfenstein hack.
Thanks, Roderick
-
Alex Henrie -
Józef Kucia -
Roderick Colenbrander