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

[Roderick Colenbrander]

On Wed, Nov 1, 2017 at 3:26 AM, Alexandre Julliard <julliard at winehq.org> wrote:
> Roderick Colenbrander <thunderbird2k at gmail.com> writes:
>
>> The amount of code sharing between ICDs, I expect to be mostly in
>> generated code and maybe a few helper functions. For now
>> I think it is best to duplicate code and longer-term if
>> a little bit of sharing makes sense put this in a staticly
>> linked helper library. I want to avoid implementing our own
>> 'winevulkan' glue ICD library in between loader and display
>> driver as I fear this will cause many issues, because the object
>> design didn't lend for this (assumes 1 ICD = 1 driver). Besides
>> some applications load the ICD directly.
>>
>> This first wave of patches gets some initial ICD infrastructure
>> in place. Enough to create a minimal Vulkan Instance and get
>> some function loading going. It will take another 6-7 patches
>> or so before 'vulkaninfo' the Vulkan equivalent of glxinfo
>> will work to some degree.
>>
>> For now the easiest way to load the ICD is to add a registry key:
>> [HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\Drivers\]
>> "C:\Windows\System32\winex11.json"=dword:00000000
>>
>> winex11.json:
>> {
>>     "file_format_version": "1.0.0",
>>     "ICD": {
>>         "library_path": "c:\\windows\\system32\\winex11.drv",
>>         "api_version": "1.0.51"
>>     }
>> }
>
> How would this be able to support multiple drivers with the same
> install? It seems to me that an intermediate library that calls the
> currently active driver would be better. What sort of issues do you
> think it would cause?
>
> --
> Alexandre Julliard
> julliard at winehq.org

Let me share a link on the overall design of Vulkan, which I think is
helpful: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md

Regarding ICD loading, there are multiple mechanisms. So far I used
the 'simple' method of adding a static registry key, but the loader
also supports a dynamic way see the section 'ICD Discovery on
Windows'. We can probably make that method work as well and deal with
winex11, wineandroid reporting the appropriate keys at runtime if they
support this capability on a given system.

Vulkan was designed outside of Win32 and doesn't use native types
(e.g. HWND). Compared to OpenGL the API has no state. All the state is
passed in through objects to the API calls, there is no 'active
context' like in OpenGL through like a wglMakeCurrent. The first
parameter (e.g. VkInstance / VkDevice) is a 'dispatchable object'
which means it contains a jump table and the ICD performs some magic
around that too.

One other thing to realize is that Vulkan is next to an OpenGL
replacement, kind of an OpenCL replacement too, you are not required
to use windows and can do offscreen rendering.

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.

Another potential area of concern is function pointer loading, see the
whole function loading chain and terminator concept in the doc.
Basically there are a couple of loading calls (vkGetInstanceProcAddr,
vkGetDeviceProcAddr and others). Each of these GetProcAddr calls you
can hook into at a different layer in the stack (could be a 'layer' or
at the bottom the ICD). If you load functions at a high layer, the
functions can be more generic and dispatch to multiple ICDs if needed,
but the lower you get the more device / driver specific a function
call with the 'same name' becomes. I'm worried about assumptions by
the loader causing confusion (function pointer compatiblity / object
type compatibility) if we are hiding multiple ICDs behind what it
thinks the ICD is.


Overall the ICD loading issues can be solved. At some point we may
want our own vulkan loader (vulkan-1.dll). This is somewhat tricky as
the loader is doing a lot of work and we should not recreate it since
it is opensource. The only problem is the license of the loader. Until
recently it was BSD licensed, so we could have pulled it in. Right now
it is Apache license. The range of options include:
1) Fork BSD licensed loader and keep it up to date.
2) Supply loader through a winegecko / mono kind of way
3) Add Apache licensed vulkan-1 loader to our codebase and keep that
directory Apache licensed.