Wine 1.7.10 Has AVI Compressor, Task Scheduler

[AnonymousCoward]

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.

CSMT + threaded-ops = 31 fps
CSMT = 20 fps
threaded-ops without CSMT= 17 fps

However, not all points in the game seem to show the difference. Some will have essentially the same FPS with CSMT and threaded-ops on or off, probably due to being a less CPU heavy area of the game.

Morrowind is known to be notoriously unoptimised and heavy on resources (as well as being single threaded) so perhaps that is why there is an effect of using both.

[dffx]

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!

[pinguinpc]

Rock of Ages works in this wine version

:cool

[stefandoesinger]

There are also a few cases where CSMT and threaded-ops can be used in tandem for even more gains E.g. Morrowind. These cases are rare, however.

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?

[pinguinpc]

Joe Danger 1 works good in this version, no more red screen

[AnonymousCoward]

CSMT also tends work with more games than Nvidia's implementation, and when it does work, it tends to have a greater impact on FPS. There are also a few cases where CSMT and threaded-ops can be used in tandem for even more gains E.g. Morrowind. These cases are rare, however.

[pinguinpc]

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 you explanation and i that as mean refer

<shameless advertisement>

[stefandoesinger]

I don't think that's quite right. My understanding of the CMST patch was that it moved the video calls out of wineserver and into their own thread

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.

[Larian]

This patches works mostly for AMD users, NVIDIA drivers have GL_THREAD_OPTIMIZATION, CSMT is equivalent for NVIDIA GL_THREAD_OPTIMIZATION but wine developers control, this explication appears on stefan dosinger anounce CMST patch for 1.7.1

I don't think that's quite right. My understanding of the CMST patch was that it moved the video calls out of wineserver and into their own thread, thereby producing an overall speedup of code execution and performance gains. This makes sense to me, as it allows the video hardware to execute code without waiting on wineserver to get around to scheduling it for processing along with all the other things it's busy with.

Did I not get that right?

[pinguinpc]

But better will be add patches from Stefan Dosinger to improve perfomance with CSMT patches or improve dual cores (= http://bugs.winehq.org/show_bug.cgi?id=11674)

This patches works mostly for AMD users, NVIDIA drivers have GL_THREAD_OPTIMIZATION, CSMT is equivalent for NVIDIA GL_THREAD_OPTIMIZATION but wine developers control, this explication appears on stefan dosinger anounce CMST patch for 1.7.1