Wine Vulkan loader (vulkan-1.dll)

[Roderick Colenbrander]

On Wed, Mar 21, 2018 at 10:36 AM, Józef Kucia <joseph.kucia at gmail.com> wrote:
> 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

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