On Mon, Mar 21, 2016 at 10:03 PM, Gabríel Arthúr Pétursson gabriel@system.is wrote:
On Tue, Mar 22, 2016 at 4:36 AM, Roderick Colenbrander thunderbird2k@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/LoaderAndLayerInt... [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