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

[Zebediah Figura]

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...

> 
> - 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?
>>>>>>
>>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201013/9324a8b4/attachment.sig>