[PATCH v2 1/5] winevulkan: Support prefixing function parameters.

[Jacek Caban]

On 12/10/21 3:00 PM, Rémi Bernon wrote:
> On 12/10/21 14:41, Jacek Caban wrote:
>> On 12/10/21 10:41 AM, Rémi Bernon wrote:
>>> On 12/10/21 10:37, Derek Lesho wrote:
>>>>
>>>> On 12/10/21 10:26, Rémi Bernon wrote:
>>>>> On 12/10/21 03:07, Jacek Caban wrote:
>>>>>>
>>>>>> To allow them being accessed from a struct.
>>>>>>
>>>>>> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
>>>>>> ---
>>>>>> v2: make remaining direct calls more similar to __wine_unix_call
>>>>>>
>>>>>>   dlls/winevulkan/make_vulkan | 59 
>>>>>> ++++++++++++++++++++-----------------
>>>>>>   1 file changed, 32 insertions(+), 27 deletions(-)
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks, it indeed fixes the issue with Control DX12.
>>>>>
>>>>> Now that it works I could measure that the series causes a ~25% 
>>>>> fps drop in that same game, from an average of 165fps to 125fps 
>>>>> measured with WINEDEBUG=+fps, while being steady near the 
>>>>> beginning of the game.
>>>>>
>>>>> Maybe this could wait after 7.0 and take some more time to explore 
>>>>> possible mitigations?
>>>> Would sending patches during the code freeze optimize this path 
>>>> count as regression fixing? 😅
>>>
>>> I guess, but I don't really see why this would be critical to 
>>> include now, I believe Wine 7.0 will still be missing critical 
>>> pieces to make winevulkan wow64 usable.
>>
>>
>> I don't think this is critical. The most important parts of the 
>> series were committed yesterday and with them, we no longer need old 
>> style Unix libs. The rest would be still nice to have. Even if we 
>> don't enable syscalls for everything, it would be nice to be prepared 
>> for them.
>>
>>
>> BTW, wow64 is not everything. For example, the patchset avoids 
>> Windows debuggers being confused by Vulkan calls.
>>
>
> I completely understand that, and we definitely want the developers to 
> be able to debug their games seamlessly.
>
> However I think it's a specific and minority use case, and most people 
> will just run the games and are only interested in having the best 
> performance they can get with their hardware.


Sure, that's why we want to make it both performant and correct, 
hopefully in the same build.


> In the same way as debug builds could be worth for developers (debug 
> symbols ofc, but we could go further than that), but are clearly not 
> something we want to have for normal users, maybe we can consider 
> having a compile-time switch for this kind of "full debugger support" 
> feature?


That's something that projects like Proton can easily do on top of that 
series until we have a full solution. But those syscalls are not only 
about debuggers, so we will need a better solution sooner or later.


> I'm not completely aware of why the full FPU context needs to be saved 
> and restored for instance, but if it's only for the debugging 
> experience, could that simply be stripped in such builds? 


Mostly what Paul wrote. It's not really possible to handle everything 
properly without those stores. Hacking around it quickly gets ugly and 
hacks can't get all cases right anyway.


Jacek