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

Paul Gofman pgofman at codeweavers.com
Fri Dec 10 08:22:47 CST 2021


On 12/10/21 17:00, Rémi Bernon wrote:
>
>
> 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?
>
If you plainly just strip saving FPU context you will get 
NtGetContextThread broken without any debugger involved. I believe 
restoring the FPU context is optimized out already for the (majority of) 
cases when it is not needed due to setting FPU context for thread. Of 
course one can hack something around and then enable only for games 
which really need that, after spending time finding out that they do.

If we talk about AVX (ymm) registers with xsavec support that is only 
actually saved if there are nonzero registers YMM registers upon the 
call. And given those registers are volatile compilers tend to often do 
vzeroupper before function calls as far as I could see (probably exactly 
to avoid context saving overhead on the syscalls otherwise present both 
under Windows and Linux without Wine involved).

Then, there is a part of non-volatile ms_abi XMM registers which are 
volatile on sysv_abi and those are allways saved in compiler generated 
prologue once ms_abi function calls sysv_abi. So going through 
Wine->Unix gate just changes the place where those are saved and in 
general a clear PE - unix part separation should be removing a great 
amount of these saves across function calls.

The part which stays excessive is volatile XMM register saves, but that 
is probably relatively minor and might be subject for fine but ugly 
optimization if we ever to introduce a "lightweight" dispatcher for 
non-blocking call. But I'd expect this overhead to be less than what we 
gain over the split for removing extra non-volatile XMM register saves.




More information about the wine-devel mailing list