https://bugs.winehq.org/show_bug.cgi?id=55262
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |performance
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- Reducing the spin count is a double-edged sword. On the one hand, it obviously means the CS takes less time spinning. On the other, it means the CS will be slower to respond to new commands if it's empty.
Increasing the query poll interval is also a double-edged sword. On the one hand, it will stop wasting time checking for queries which probably aren't ready yet, and thereby allow the CS thread to process commands faster. On the other, it means that we will notice queries that *are* ready later.
The effect is that both of these may very well end up being application- and driver-specific whether modifying them helps, hurts, or has no effect.
Now, in practice, wrt the spin count, it used to be that streaming buffer mapping and UpdateSubResource (which are both very common operations) were synchronous, which, among other things, had the effect that the CS would be empty more often, and that's one reason why the spin count had been set so high. That's no longer the case, and as a result we believe that at this point the spin count can be lowered, and perhaps even removed entirely (as you have experiemented with).
As for query polling, I'm less familiar with the concerns there, but it's certainly possible that the interval we have is categorically too low. We may also want to do polling based on time instead of spin count (i.e. poll at some interval after a command finishes).
The main point is that it can be dangerous to test one application and then assume that the updated settings are better for all applications.