On 12/10/21 15:43, Paul Gofman wrote:
On 12/10/21 17:36, Rémi Bernon wrote:
Well as far as I could see, in all the measurements I've made for a long while xsavec64 / xrstor64 were the highest hitters, and something like 10% to 30% CPU time spent on these two instructions.
I don't know if that should be part of the "optimized vast majority of cases", but it's the same with Proton or with current upstream Wine. In any case it's way worse and nowhere near the overhead we had a year ago with SSE XMM register spilling from the ABI transitions generated by the compiler.
It is strange. Unlike the current Proton, xrstor64 should not appear at all with upstream Wine (unless the app is setting the context for threads constantly). Are you sure that is the case with upstream? In that case maybe there is some genuine bug or easy optimization opportunity involved.
Then, for xsavec64, it is doing saves in one instruction which otherwise split in many with compiler generated registers saves. Can it be it affects its place in perf top? Overall I don't think perf can show anything meaningful on such a fine measurement level due to sampling measurements specifics and CPU instruction flow specifics. A good and simple way would be to measure the time over a large amount of calls with rdtsc with and without xsavec, in the real game by instrumenting the syscall dispatcher with that measurement (fwiw I have such an instrumentation for relay stubs locally but not for syscall dispatcher atm).
I'm sure perf is very able to tell us useful information. That it uses sampling doesn't matter as it's not something that only happens randomly and spuriously, but a constant overhead, and if 10% of the samples now fall into the __wine_syscall_dispatcher, it's just very likely that it just takes 10% more CPU time.
Now, because I'm a bit annoyed that perf usage is always questioned, I also did the test:
1) With just this patch series applied, I get ~125fps, ~10% global CPU time spent in __wine_syscall_dispatcher_prolog_end (highest perf top hitter), of which 76% are assigned directly to the xsavec64 instruction.
2) Commenting out xrstor64, in __wine_syscall_dispatcher, I get roughly the same thing, unsurprisingly.
3) Commenting out both xsavec64 and xrstor64, I get ~150fps, ~3% global CPU time spent in the dispatcher (still highest hitter but close to d3d12_desc_copy_range, which is the main one without this series), and of which it is spread quite evenly over all the dispatcher instructions.
Can we put a little bit more trust in the tool now? I'm not saying it's always right, and that CPU time wouldn't be spent or wasted by the game otherwise, but here, it's clearly telling us that we are adding some overhead and where it comes from.