<div dir="ltr"><div dir="ltr">Hi Liam,<br><br>On Sep 9, 2020, at 03:44 AM, Liam Middlebrook <<a href="mailto:lmiddlebrook@nvidia.com">lmiddlebrook@nvidia.com</a>> wrote:<br>> Hi Brendan,<br>><br>> On 9/8/20 1:22 PM, Brendan Shanks wrote:<br>>> Hi Liam,<br>>> <br>>>> On Sep 8, 2020, at 12:46 PM, Liam Middlebrook <<a href="mailto:lmiddlebrook@nvidia.com">lmiddlebrook@nvidia.com</a>> wrote:<br>>>><br>>>> Tested with Vulkan CTS and WINEVULKAN_QUIRK_IGNORE_EXPLICIT_LAYERS.<br>>>><br>>>> Signed-off-by: Liam Middlebrook <<a href="mailto:lmiddlebrook@nvidia.com">lmiddlebrook@nvidia.com</a>><br>>>> Signed-off-by: Daniel Koch <<a href="mailto:dkoch@nvidia.com">dkoch@nvidia.com</a>><br>>>> ---<br>>>> v2: fixup comment style<br>>>><br>>>> dlls/winevulkan/vulkan.c | 17 +++++++++++++++++<br>>>> 1 file changed, 17 insertions(+)<br>>>><br>>>> diff --git a/dlls/winevulkan/vulkan.c b/dlls/winevulkan/vulkan.c<br>>>> index a8beef126bd..19093d47390 100644<br>>>> --- a/dlls/winevulkan/vulkan.c<br>>>> +++ b/dlls/winevulkan/vulkan.c<br>>>> @@ -662,6 +662,7 @@ VkResult WINAPI wine_vkCreateInstance(const VkInstanceCreateInfo *create_info,<br>>>>      const VkApplicationInfo *app_info;<br>>>>      struct VkInstance_T *object;<br>>>>      VkResult res;<br>>>> +    HKEY key;<br>>>><br>>>>      TRACE("create_info %p, allocator %p, instance %p\n", create_info, allocator, instance);<br>>>><br>>>> @@ -679,6 +680,22 @@ VkResult WINAPI wine_vkCreateInstance(const VkInstanceCreateInfo *create_info,<br>>>>      }<br>>>>      object->base.loader_magic = VULKAN_ICD_MAGIC_VALUE;<br>>>><br>>>> +    /* Load optional WineVulkan quirks bits from registry, see vulkan_private.h<br>>>> +     * for a list of quirks.<br>>>> +     */<br>>> <br>>> There’s a specially-formatted comment that is used to highlight Wine registry keys, like:<br>>> <br>>> /* @@ Wine registry key: HKCU\Software\Wine\Vulkan */<br>> <br>> Ah cool, I was looking through examples in other places and must have <br>> missed that. I'll add that in later on, but I figure we may want to hash <br>> out the below a bit more first, before I send any follow-up patches.<br>><br>>> <br>>> Also, this seems like a good fit to support AppDefaults in the registry.<br>><br>> Yeah, I think that makes sense to do. Rather than using the process name <br>> like is done elsewhere, how would you feel about making use of <br>> pApplicationName and pEngineName from VkApplicationInfo?<br>><br>> The regkey structure could be something like:<br>>     HKCU\Software\Wine\Vulkan\ApplicationName\%pApplicationName%\Quirks<br>>     HKCU\Software\Wine\Vulkan\EngineName\%pEngineName%\Quirks<br>><br>> Although it'd also be nice to try to account for versions there, but <br>> maybe doing that from the registry isn't the right spot. Ideally we <br>> shouldn't really need to be adding any more of these <br>> application-specific workarounds anyways, but for older poorly-behaving <br>> applications they'll always be needed.<br>><br>> Another though I had on this (+CC Georg) was that we should probably <br>> invert WINEVULKAN_QUIRK_ADJUST_MAX_IMAGE_COUNT so that the default is <br>> zero, possibly rename to add a _DONT_.<br><br>I agree, inverting it makes sense because we want that quirk to be activated<br>by default. It fixes a very common mistake that will probably keep getting<br>made, so maintaining app profiles for it seems like a lot of work for no<br>reason and a functional regression at this point.<br>And since the behavior with that quirk enabled is closer to what windows<br>drivers report, there should be no application that breaks because of it.<br><br>Thanks,<br><br>Georg<br><br>><br>> Thinking further on quirk defaults, I wonder if they should be handled <br>> as binary, or if trinary is a better fit (unset, forced on, forced off). <br>> Right now the quirks bits have us choosing some reasonable default for <br>> all applications, and then either using the prospective regkey to enable <br>> a quirk, or having winevulkan pick up on some runtime-specific state to <br>> determine if a quirk needs to be enabled or not. Although if we're <br>> thinking down that route, maybe it would be easiest to have each quirk <br>> split to a separate regkey-value, and then track those settings in a <br>> structure.<br>><br>><br>> Although, maybe that's all a bit much, and we should really just grab <br>> the current EXE name for any App specific matching, and use the single <br>> Quirks regkey-value. Curious to hear your thoughts on this.<br>><br>><br>> Thanks,<br>><br>> Liam Middlebrook<br>><br>>> <br>>> Thanks,<br>>> Brendan<br>>> </div><br></div>