[PATCH] vulkan-icd: Add stub dll.

[Roderick Colenbrander]

On Mon, Mar 21, 2016 at 10:03 PM, Gabríel Arthúr Pétursson
<gabriel at system.is> wrote:
> On Tue, Mar 22, 2016 at 4:36 AM, Roderick Colenbrander
> <thunderbird2k at gmail.com> wrote:
>> Hi Gabríel,
>>
>> Thanks for your patch. Depending on the direction where you intend to
>> take this, I'm not sure if we need this dll. Note I haven't done much
>> with Vulkan myself yet, but following the analogy of opengl32, the ICD
>> portion should be inside winex11.drv (and our other drivers). It is
>> what should export this function call ultimately and similar needs to
>> host the x11 related vulkan code, which has to live in here as well,
>> because such code is not supposed to live outside winex11.drv.
>>
>> Thanks,
>> Roderick
>
> The ICD is intended for use by Khronos' official Vulkan loader, which
> typically is shipped as a separate DLL, vulkan-1.dll, although
> applications may statically link the loader. The interaction between
> an ICD and a loader is well documented[1].
>
> I have provisional patches available on my Github repository[2]. It's
> not yet fully complete though, missing the WSI integration. My plan is
> to link to winex11.drv and map a HWND to xlib's Display* and Window.
> Maybe that's not the best solution, in which case, I'd love to hear
> your suggestions.
>
> [1] https://github.com/LunarG/VulkanSamples/blob/master/loader/LoaderAndLayerInterface.md#vulkan-installable-client-driver-interface-with-the-loader
> [2] https://github.com/polarina/wine/commits/vulkan

Thanks for sharing some of the material. I did some more reading last
night and now. I was already leaning towards having to implement the
ICD interface since now it is properly documented, which wasn't the
case for OpenGL. I don't like the fact too much that applications can
statically link the loader portions yikes, which will probably cause
issues down the road.

The main thing, which I think needs a lot of attention is the design
of the driver model and how to load the native vulkan driver. This is
quite tricky and I'm not sure yet what the right way is, technically
this also still needs solving for wine's opencl implementation, which
is also not correct.

My initial feeling is that loading of the vulkan library needs to live
next to the WSI implementation, which I think should be in the wine
display drivers.

The part which I'm not sure about is how and if we want to handle
multiple Linux vulkan ICD drivers. Assuming big chunks of our vulkan
code would live in the display driver, I guess it would somehow act
like a 'proxy' to the Linux ICD drivers.

I haven't used the vulkan APIs yet, so I don't have a good feeling for
all aspects yet. Based on what I described, I wonder to what extend we
need vulkan-icd.dll. Assuming there is enough code we can share
between future other vulkan backends in wine for Android and who knows
some day crApple when they support Vulkan, it may make sense to have
this dll. Else maybe it should live in the ICD implementation, which
I'm leaning towards should live as part of the display driver. (Maybe
winex11.drv should just be registered in the registry as an ICD, not
sure)

I don't want to scare you, but window management will also be quite a
challenge. Handling of applications using a full window for vulkan is
probably easy since there is a direct mapping to an x11 window. If
vulkan allows child window rendering (which I guess it does), that
will need some special handling. The challenge is that we only have 1
X11 window per application. For OpenGL on Linux we use a hack by
rendering to a pixmap and copying the output back on the X11 window.
Not sure what can be done for Vulkan. I would say this is not high
priority yet, however our vulkan wsi layer shouldn't need a complete
redesign to support this.

I will have a closer look at Vulkan as well in the coming days and
maybe able to help out a little bit on the side, but my time is a bit
limited these days :(

Thanks,
Roderick