Direct3D "CSMT" in wine-2.6

Questions about Wine on Linux
Locked
hverbeet
Level 1
Level 1
Posts: 8
Joined: Fri Apr 14, 2017 6:41 am

Direct3D "CSMT" in wine-2.6

Post by hverbeet »

Since the "multi-threaded command stream" is one of the major new features in wine-2.6, and not everyone is in the habit of reading Wine commit messages, it seems appropriate to make a post here clarifying a few things:
  • The CSMT feature is disabled by default, and is likely to stay that way until after the wine-3.0 release. While no date has been set for that release, my expectation is that that will happen sometime in early 2018.
  • CSMT is controlled through the registry key HKCU/Software/Wine/Direct3D/csmt, which is a DWORD value. Setting the key to 0 will disable the feature, while setting it to 1 will enable the feature. Other values should be considered reserved. Currently any non-zero value will enable the CSMT feature, but it's conceivable they will acquire more specific meanings in the future.
  • Despite a clearly unverified article on a certain self-proclaimed review/benchmark site, and as noted in the commit message for the CSMT feature, the code in wine-2.6 is not meant to improve Direct3D rendering performance. The intended purpose is to replace the "StrictDrawOrdering" feature, and solve issues like applications querying occlusion query results from a different thread than the thread that created that occlusion query. If anything, performance is currently expected to be slightly worse with CSMT enabled than without.
  • As also noted in the earlier mentioned commit message, the potential for improved performance does exist. The intention is to make the CS thread run asynchronously in wine-2.7 or perhaps wine-2.8, with likely further performance improvements after that.
In terms of testing and reporting bugs, that means the following:
  • Please test your applications with CSMT enabled. If enabling CSMT introduces rendering errors or otherwise breaks an application that's something we'd like to know about. Minor performance regressions with CSMT enabled are expected and not a concern at this point. After asynchronous CSMT lands performance regressions do become a concern.
  • If you have an application that currently requires "StrictDrawOrdering", please test whether enabling CSMT resolves the issue. "StrictDrawOrdering" is deprecated by CSMT and will likely be removed after wine-3.0. We'd like to fix any remaining issues before that.
wildtux
Level 3
Level 3
Posts: 56
Joined: Sat Aug 13, 2016 10:05 am

Re: Direct3D "CSMT" in wine-2.6

Post by wildtux »

Remind that csmt feature is to be add by regedit or manually:
"csmt"=dword:00000001
macchinetta

Re: Direct3D "CSMT" in wine-2.6

Post by macchinetta »

If anything, performance is currently expected to be slightly worse with CSMT enabled than without.
Sorry... but is same CSMT patch that was included in wine-staging?

In most cases I have really best performance with CSMT enabled, than with CSMT disabled.
macchinetta

Re: Direct3D "CSMT" in wine-2.6

Post by macchinetta »

I've found answers in page about performance of wiki:
CSMT has been initially developed as a way to enhance wined3d performance, with the "theory" being that by splitting the potentially expensive GL calls out of the application thread we can quickly return to the application code and hopefully lessen our CPU-side woes. That turned out to work pretty well but with a caveat: some commands (e.g. mapping buffers) actually NEED to wait for the operation to complete since they have to return data to the application. Without some "tricks" when we get one of those commands we have to effectively wait until all the commands queued before it complete their execution, which means that the application thread has to block and wait, potentially throwing a lot of the performance improvement out of the window.
The version of CSMT initially introduced in "official" Wine does without some of those tricks (specifically, those that weren't generally safe) and has some room for further performance improvements. It still works perfectly fine as a better replacement of the StrictDrawOrdering option.
Be patient. :)
Locked