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

[Zebediah Figura]

On 10/13/20 9:34 PM, Joshua Ashton wrote:
> 
> 
> 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.

Maybe so (though if what I said is correct, it's not obvious to me why
there's anything fundamentally wrong with the design), but that's
somewhat orthogonal to the point here. Provided the Vulkan headers are
fixed so that non-win32 drivers can use the relevant types, is there any
reason why this extension can't be implemented?

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

I can't think of anything particularly unusual I'm doing, but I'll keep
it in mind in case I get more reports of this, thanks.

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


-------------- 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/b33b3310/attachment.sig>