[PATCH] vulkan-icd: Add stub dll.

[Gabríel Arthúr Pétursson]

On Tue, Mar 22, 2016 at 4:43 PM, Roderick Colenbrander
<thunderbird2k at gmail.com> wrote:
> 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.

Applications statically linking the loader shouldn't cause issues.

I believe that if we decide to ship a loader with Wine, and I assume
we want to do that, it would probably be best/simplest to use Khronos'
loader. That loader, unmodified, is what I'm currently using to run
Vulkan applications against the ICD implementation.

> 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.

Handling multiple ICDs is entirely up to the loader.

I believe supporting multiple Vulkan ICD drivers is worth it. Software
implementations of Vulkan, for example, could be installed alongside
Wine's ICD and not need any special interaction with Wine or the host.
The loader is also responsible for hooking up any explicit or implicit
layers installed, which is needed for some applications to function
properly, such as the Steam overlay and RenderDoc.

> 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)

Significant parts of the ICD has to with plumbing between Windows'
loader and the host's loader.

WSI integrations are exposed in Vulkan as optional extensions. It is
valid for implementations not to support them; applications that only
require compute or off-screen rendering don't need them.

> 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.

Vulkan does not allow child rendering. On Windows, an application
passes a pair of HINSTANCE and HWND to the implementation. On Linux
with XLib, a pair of Display* and Window is passed. Mapping between
those two should be trivial.

With that given, I admit I have not yet implemented the WSI
integration so unforeseen issues may or may not arise. I'll find out
shortly. :)

> 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 :(

I'm more than happy to collaborate with anyone interested in helping
out. If you find the time, feel free to drop me a line.