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
On Mon, Mar 21, 2016 at 8:26 PM, Gabríel Arthúr Pétursson gabriel@system.is wrote:
Signed-off-by: Gabríel Arthúr Pétursson gabriel@system.is
configure.ac | 1 + dlls/vulkan-icd/Makefile.in | 2 ++ dlls/vulkan-icd/vulkan-icd.spec | 1 + 3 files changed, 4 insertions(+) create mode 100644 dlls/vulkan-icd/Makefile.in create mode 100644 dlls/vulkan-icd/vulkan-icd.spec
diff --git a/configure.ac b/configure.ac index 77c54c8..04ddb54 100644 --- a/configure.ac +++ b/configure.ac @@ -3310,6 +3310,7 @@ WINE_CONFIG_DLL(vnbt.vxd,enable_win16) WINE_CONFIG_DLL(vnetbios.vxd,enable_win16) WINE_CONFIG_DLL(vssapi) WINE_CONFIG_DLL(vtdapi.vxd,enable_win16) +WINE_CONFIG_DLL(vulkan-icd,,[implib]) WINE_CONFIG_DLL(vwin32.vxd,enable_win16) WINE_CONFIG_DLL(w32skrnl,enable_win16) WINE_CONFIG_DLL(w32sys.dll16,enable_win16) diff --git a/dlls/vulkan-icd/Makefile.in b/dlls/vulkan-icd/Makefile.in new file mode 100644 index 0000000..c41bf8f --- /dev/null +++ b/dlls/vulkan-icd/Makefile.in @@ -0,0 +1,2 @@ +MODULE = vulkan-icd.dll +IMPORTLIB = vulkan-icd diff --git a/dlls/vulkan-icd/vulkan-icd.spec b/dlls/vulkan-icd/vulkan-icd.spec new file mode 100644 index 0000000..db3616e --- /dev/null +++ b/dlls/vulkan-icd/vulkan-icd.spec @@ -0,0 +1 @@
+@ stub vk_icdGetInstanceProcAddr
2.7.0
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
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
On Tue, Mar 22, 2016 at 4:43 PM, Roderick Colenbrander thunderbird2k@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.
-
Gabríel Arthúr Pétursson -
Roderick Colenbrander