Almost. Wineserver never had anything to do with d3d or opengl rendering. Currently all OpenGL calls are done in the application thread that performs the d3d calls. My CSMT patches move GL calls into a separate thread. The exact effect this causes depends on how the application behaves, but essentially:
If the application is single threaded, a second CPU core is utilized. In ideal situations this doubles performance.
If the application is multi-threaded, we can do draw order synchronization much cheaper by just synchronizing writes to our ring buffer instead calling glFlush all over the place. The gains here can be huge, e.g. Call of Duty Modern Warfare 2 had 5 times the original framerate (with an additional hack that's not in my patches yet).
The multithreaded command stream does not fix all performance problems, but it fixes a few fundamental issues that were preventing us from getting anywhere close to Windows on multicore systems.
As a few people noticed, some of the CSMT patches are already in Wine. I'm working on an updated patchset for Wine 1.7.10 that should be available within a few days, most likely by Monday.
<shameless advertisement>My work and that of most other Wine developers is funded by CodeWeavers. You can support us by purchasing CrossOver subscriptions. CrossOver 13 also contains the multithreaded command stream.</shameless advertisement>
CSMT is conceptually the same as Nvidia's __GL_THREADED_OPTIMIZATIONS. The main difference is that it is implemented in our code, so it works on all GPUs / drivers and we don't have to argue with Nvidia about glMapBufferRange.
To clear up a common misunderstanding (i.e. Alky...): wineserver is not some magic host process that "interprets" Windows applications or something like that. It is an IPC helper application that implements functionality available in the Windows kernel, but not available in a Unix kernel. Examples are the Windows registry and corner cases in inter process communication.
Thanks for all this Stefan! I'm excited to see what patches you have for us next week.
I'll likely pick up a Crossover subscription next paycheck, even though I prefer to use Wine (my system is already configured with a variety of Wine prefixes and it's kinda tricky to work Crossover into that). I like to support where I can!
This is interesting. It's plausible that this happens in some cases, but it'd mostly be in games where wined3d itself generates considerable CPU load. Usually this is not the case, wined3d should consume < 5% CPU time. It'd have to be higher than that to make up for the overhead of the additional indirect command stream queue inside the GL driver.
How big are the gains in Morrowind with CSMT + threaded-ops compared to just CSMT alone?
Just did a quick test with the 1.7.4 version; I'll test with the git repo later.