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

Zebediah Figura zfigura at codeweavers.com
Fri Dec 10 12:04:38 CST 2021


On 12/10/21 12:00, Jacek Caban wrote:
> On 12/10/21 6:10 PM, Zebediah Figura wrote:
>> One possible optimization that Paul and I had discussed a while back 
>> was to allow for the possibility of "masked" or "uninterruptible" 
>> syscalls, that is, syscalls that cannot be directly interrupted with 
>> SuspendThread(). The idea is that instead of saving the whole 
>> nonvolatile context up front, you instead set a flag in the syscall 
>> dispatcher (when SIGUSR1 is received) that tells the restore path to 
>> save the whole context and break into the suspend handler.
>>
>> This would only be usable for calls which don't sleep (or don't sleep 
>> for a meaningful amount of time), but as I understand that could 
>> include most Vulkan calls, including vkUpdateDescriptorSets and other 
>> important ones.
> 
> 
> Note that it's not just SuspendThread() that would be affected, but also 
> system APCs.

Right, system APCs would be delayed as well. The point is that 
regardless it wouldn't be holding anything up because it'd only be used 
for calls that complete immediately.

It's possible there's some problem that would prevent this from working, 
though. I can't say I've tried to implement it, or really thought 
through it exhaustively.

> 
> 
> In cases like internal Vulkan syscalls we have a bit less compatibility 
> constrains than in ntdll, because those are not syscalls called directly 
> by applications. If xsave is causing a problem, we can put CPU into a 
> state when it's cheaper. We discussed earlier doing vzeroupper, we could 
> reset even more parts of the context to make xstor cheaper.
> 
> 
> That, however, can help only with context store part of syscalls. There 
> are other things like %fs base switching on the horizon.

Sure, but %fs switching is something that can't be avoided at all, as I 
understand, plus it's only relevant if using wow64 support.



More information about the wine-devel mailing list