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

[Jacek Caban]

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 also wouldn't bet on it being easily possible and in a way that's 
> acceptable for the code freeze (ie: without too many or ugly changes).
>
> It would also imho impede an eventual Proton rebase, as we'll not want 
> that kind of regression so we'd probably have to revert the changes, 
> and not even try to fix the regression or make some ugly hacks to 
> workaround it. 


Note that only the last patch from the series is risky for performance. 
That patch is also small and easy to tweak or revert, if needed, so I'm 
sure we will not anything uglier than that. Maybe we could just disable 
it for command buffer (and possibly some other frequent calls) for now 
and have the codebase otherwise ready and tested.


Thanks,

Jacek