[PATCH 2/3] winevulkan: Implement extension faking mechanism

[Joshua Ashton]

On 10/14/20 2:42 AM, Zebediah Figura wrote:
> On 10/13/20 7:02 PM, Joshua Ashton wrote:
>> Zeb, it's in vulkan_win32.h.
>> You can't include it on Linux or any other platform for that matter.
>> If you read the xml, it's marked as being `platform="win32"`.
>> It's a Windows extension.
>>
>> To move it out of there on a Vulkan level, we'd need to make a sequel
>> and different platform-specific extensions.
>> Inherently making this version unsupportable in non-Windows drivers.
>>
>> It makes more sense to read the line of VK_KHR_win32_surface support
>> more as if you want surfaces (ie. not headless) than focusing on the
>> platform part of things.
> 
> Can you please explain why this is the case? The extension seems to have
> been intentionally written in a platform-agnostic manner—except for the
> parts which interact with platform-specific extensions, and those parts
> are pretty clearly described as optional.
> 
> If "platform=win32" has relevance to the API, and can't be changed
> without breaking backwards-compatibility, this fact should really be
> reflected in the documentation. As it is, it's not obvious to me that
> this problem can't be resolved by simply moving those definitions out of
> the "vulkan_win32.h" header and into "vulkan_core.h". Perhaps there's
> places that I haven't found to look, though...
> 
It's more the fact that this extension was made wrong. The platform 
specific parts should be parts of their own extensions that are 
dependent on the base.

Currently all platform-specific structures in other extensions are 
exposed this way (ie. win32_surface, and stuff.)

This also plays into how the script to build the headers works.

Also for some reason your emails tend to take like an hour to get to me 
through the mailing list but everyone else's is fine? I'm not sure why...

- Joshie 🐸✨
>>
>> - Joshie 🐸✨
>>
>> On 10/14/20 12:37 AM, Georg Lehmann wrote:
>>> On 14.10.20 01:23, Zebediah Figura wrote:
>>>> On 10/13/20 4:54 PM, Joshua Ashton wrote:
>>>>> Figured I should add the reason why, is because just passing it through
>>>>> will cause the device to fail to be created because nobody supports
>>>>> VK_EXT_full_screen_exclusive on Linux.
>>>> Sure, but they could.
>>>>
>>>>> It's an entirely Windows-centric extension.
>>>> Well, no, it's not really, but it does include some API-level
>>>> integration with win32 monitors *if* KHR_win32_surface is supported. In
>>>> that case, as far as I can see, we don't even need to do anything,
>>>> because the VkSurfaceFullScreenExclusiveWin32InfoEXT structure would
>>>> just be ignored.
>>>
>>>
>>> No, according to the vulkan spec a
>>> VkSurfaceFullScreenExclusiveWin32InfoEXT is illegal in any chain
>>> unless the full screen + win32 surface exts are enabled. In practice,
>>> this will break layers like renderdoc. So we would still need code to
>>> remove that struct from pNext chains.
>>>
>>>
>>> Georg
>>>
>>>
>>>> Not that this necessarily means that lower-level drivers should be the
>>>> ones to implement the extension, but if nothing else, this information
>>>> isn't present at all in the patch.
>>>>
>>>> Also, do we really need a generic mechanism for this, wired into
>>>> make_vulkan? Can't we just handle this extension specially in
>>>> wine_vk_device_convert_create_info()?
>>>>
>>>>> - Joshie 🐸✨
>>>>>
>>>>> On 10/13/20 10:42 PM, Joshua Ashton wrote:
>>>>>> winex11/winemac only does this for instance extensions.
>>>>>>
>>>>>> VK_EXT_full_screen_exclusive is a device extension.
>>>>>>
>>>>>> - Joshie 🐸✨
>>>>>>
>>>>>> On 10/13/20 10:35 PM, Zebediah Figura wrote:
>>>>>>> Why not do this the normal way, i.e. by modifying the code in winex11
>>>>>>> and winemac?
>>>>>>>
>>>>>>> Also, what's the point of faking the extension like this? Why not
>>>>>>> just
>>>>>>> pass it through?
>>>>>>>
>>>>
>>>
>>
> 
>