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

[Rémi Bernon]

On 12/10/21 11:08, Paul Gofman wrote:
> On 12/10/21 12:41, 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 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.
>>
>> Cheers,
> 
> Yeah, considering that:
> 
> - winevulkan, opengl and potentially a bit of other stuff unfortunately 
> have more issues for 32 on 64 without explored solution yet and even in 
> the most optimistic case won't be there around 7.0;
> 
> - there is an example of the game which shows measurable performance drop;
> 
> - it is the last day before the code freeze and details are not yet 
> known and it is not clear what fixing the performance drop will take.
> 
> I'd also suggest to explore that first without a rush.
> 

Also fwiw regarding perf tool, the recent ntdll.dll 64bit base address 
change makes it fail to match symbols correctly, it needs to be put in 
the 32bit address space again to make any meaningful measurement with perf.
-- 
Rémi Bernon <rbernon at codeweavers.com>