[PATCH 00/10] winex11: Add Vulkan ICD.

[Roderick Colenbrander]

On Wed, Nov 1, 2017 at 3:14 PM, Alexandre Julliard <julliard at winehq.org> wrote:
> Roderick Colenbrander <thunderbird2k at gmail.com> writes:
>
>> The role of the Vulkan loader is to manage all the different ICDs on
>> the system and inject the layers at the correct points. My fear is
>> that if we add our own 'winevulkan' library in between it will become
>> another loader. For APIs such as vkEnumeratePhysicalDevices or
>> vkEnumerateInstanceExtensionProperties we would need to aggregate the
>> values across winex11, winewayland, etc, which is what the loader does
>> for us. This is painful and we need to figure ways ourselves to load
>> said driver.
>
> On the contrary, you don't want to aggregate the values. It wouldn't
> make sense to load both winex11 and winewayland, you can only use the
> one that corresponds to what user32 is currently using for that process.
> So a separate winevulkan would simply query the driver corresponding to
> the desktop window, and rely on user32 to load it. And for the offscreen
> rendering case, it wouldn't even have to go through the graphics driver
> at all.

I need to think a bit on what could be done in such an approach. In
OpenGL terms there is not a clear separation between the GL calls and
the WGL aspects, they are intertwined. Building a winevulkan requires
untwinining these aspects, I'm not sure how cleanly that can be done
as the APIs weren't designed for it. Which is why I hoped to go the
Vulkan PNP registry way (like vulkan windows operates).

One example of the intertwining. One of the 'contexts' created in
Vulkan is a VkInstance through vkCreateInstance call. Vulkan loves
passing massive data structures through. If the application requests
the surface extension, it wants graphics rendering else it may just
want to do compute. To solve this situation, I would need to parse the
extension field and pass it to winex11 and let it do a native
vkCreateInstance call and do its X11 magic OR or if no graphics just
finish completion of the call in winevulkan and have it create the
native instance by calling vulkan itself.

There are likely other calls, which which need to passed through to
winex11 or not based on parameter parsing.

Function call loading is another thing. Both winevulkan and winex11
would need to make Vulkan calls. Either both libraries load them or
one passes a function table (with potentially wayland/x11/..) specific
calls back.

The higher and lower vulkan layers will be fairly intimate. There are
subfields in Vulkan objects (VkInstance, VkDevice) which a winex11 may
fill or if no graphics just winevulkan. Generic Vulkan calls like
vkEnumeratePhysicalDevices or other calls need to operate on them.


> Your approach would require all the Wine graphics drivers to support
> being loaded behind user32's back, and refuse to work if they aren't the
> active driver for the current desktop. That's a lot of complication, for
> no benefit that I can see. Trying to force a 1:1 mapping between the
> Vulkan ICD loader and the user32 graphics drivers would be a mistake IMO.

I see your concerns. We could prevent loading of a graphics driver if
it wasn't picked. Luckily there are only 2 entry points to ICDs.
Another approach as I said is to use the PNP related registry keys,
which only loaded display drivers can set.

Overall my main concern is that we need to figure out how to bend
Vulkan into being like a GL and WGL, while the APIs weren't designed
for it. There will be a large amount of intimacy between the layers
just because of shared data structures different APIs need to act.