Wine Vulkan loader (vulkan-1.dll)

Józef Kucia joseph.kucia at gmail.com
Wed Mar 21 12:36:43 CDT 2018


On Sat, Mar 17, 2018 at 7:39 PM, Roderick Colenbrander
<thunderbird2k at 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.
>
> 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?

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



More information about the wine-devel mailing list