[PATCH 5/5] winevulkan: Add executable name Quirk regkey handling

[Liam Middlebrook]

On 9/15/20 12:52 AM, Alexandre Julliard wrote:
> Liam Middlebrook <lmiddlebrook at nvidia.com> writes:
> 
>> +    if (!wine_vk_get_exe_name(exe_name, MAX_PATH))
>> +        exe_name[0] = '\0';
>> +
>>       /* Match regkey settings in the following order, breaking early if settings
>>        * are found:
>>        *     pApplicationInfo->pApplicationName
>>        *         @@ Wine registry key: HKCU\Software\Wine\Vulkan\pApplicationName\<pApplicationName>
>>        *     pApplicationInfo->pEngineName
>>        *         @@ Wine registry key: HKCU\Software\Wine\Vulkan\pEngineName\<pEngineName>
>> +     *     executable name
>> +     *         @@ Wine registry key: HKCU\Software\Wine\Vulkan\exeName\app.exe
>>        *     global defaults
>>        *         @@ Wine registry key: HKCU\Software\Wine\Vulkan
> 
> Do we really need to invent a new mechanism for this?  All other modules
> use HKCU\Software\Wine\AppDefaults\<exename> for that sort of thing.
> 

For the executable name matching. I'm fine with using the existing 
HKCU\Software\Wine\AppDefaults\<exename>\ pattern that other modules are 
using. I had picked the format above to be consistent with this newer 
syntax I came up with for VkApplicationInfo, but I agree that 
consistency with the rest of WINE seems like a better fit overall. I'll 
change that to be consistent with the other AppDefaults regkeys in WINE.

Looking at the other APIs which have AppDefaults keys available, it 
doesn't appear that any of these APIs have a mechanism which serves 
quite the same purpose that Vulkan does with VkApplicationInfo (namely 
the application providing information about itself to the 
implementation). I guess there could be an argument that this is 
generically possible by keying off of values from VS_VERSIONINFO, but I 
don't think it's quite the same as that's a mechanism of Windows rather 
than the APIs themselves. The Vulkan specification notes the following 
about VkInstanceCreateInfo.pApplicationInfo [1]:

> this information helps implementations recognize behavior inherent to classes of applications

I think it makes sense moving forward, as we see more applications 
adopting use of Vulkan, to utilize the mechanisms the API affords 
implementations for identifying a running application.

Additionally, this information is already being used within WineVulkan 
to match the idTech engine [2]. There are also a few different Vulkan 
driver implementations [3], [4], [5], which use this for enabling 
per-application/per-engine settings.

While writing this out I also found an issue with patch 3/5 where I was 
incorrectly assuming that pApplicationInfo would always be a valid 
pointer we could read from. I'll fix that locally for now, but wait to 
send out v2 of the series until we bottom out on the discussion here.


Thanks,

Liam Middlebrook


[1] - 
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VkInstanceCreateInfo
[2] - 
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winevulkan/vulkan.c#l728
[3] - 
https://github.com/GPUOpen-Drivers/xgl/blob/dev/icd/api/app_profile.cpp#L100
[4] - 
https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/vulkan/radv_device.c#L557
[5] - 
https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/intel/vulkan/anv_device.c#L766