[PATCH v2 1/2] winevulkan: Manually fixup struct alignment for VkPipelineCreationFeedback.

[Zebediah Figura]

On 2/15/22 14:13, Georg Lehmann wrote:
> 
> 
> On 15.02.22 19:49, Zebediah Figura wrote:
>> On 2/9/22 11:20, Georg Lehmann wrote:
>>>
>>>
>>> On 09.02.22 18:07, Zebediah Figura wrote:
>>>> On 2/9/22 10:39, Georg Lehmann wrote:
>>>>> We can't reasonably auto generate this because it's output in an
>>>>> otherwise input pNext chain.
>>>>
>>>> Aren't we going to need to do that anyway, though, for many other
>>>> functions, for wow64 support?
>>>>
>>>> It seems like it'd be more worthwhile to add infrastructure for
>>>> automatically generating this, or at least some of it.
>>>>
>>>
>>> As far as I can tell this is the only pNext chain like this. We don't
>>> handle pure output chains, that's something that needs to be automated
>>> for wow64. But this issue is an unique edge case.
>>
>> I'll admit this doesn't make me feel comfortable, not when Vulkan is a
>> fast developing API that we are making an effort to keep up with. I.e.
>> even if there aren't any others now it seems not unlikely we'll come
>> across more of these in the future. And if we can find a solution that
>> allows handling partial and wholly output chains in one breath, that
>> seems nice...
>>
>> It seems like most such structs are marked "returnedonly"; can we use
>> that to determine what needs output conversion? It's missing from
>> VkPipelineCreationFeedbackCreateInfo, but maybe that's an error.
>>
> 
> It's not quite as simple because some structs are input in one chain but
> output in another. Like all the feature structs, which you use to query
> the available features but also to enable them on device creation.
> Generally everything in a const void* pNext chain is input and
> everything in a void* pNext chain is output, but
> VkPipelineCreationFeedbackCreateInfo is the exception to that rule.

I see.

Do you think this is the sort of rich information we could introduce 
into the official XML? It seems potentially useful for other purposes 
than ours. E.g. other translation layers, such as language bindings, 
could potentially make use of it.

Granted, if it's only the one structure for now, and we can reliably use 
the "const" pointer, maybe it's not worthwhile, but I also don't want to 
get caught off guard again.