Wine 1.7.10 Has AVI Compressor, Task Scheduler

[phoronix]

Phoronix: Wine 1.7.10 Has AVI Compressor, Task Scheduler

Wine 1.7.10 is out this Friday as the first bi-weekly development release of 2014...

http://www.phoronix.com/vr.php?view=MTU1OTM

[Pepes]

Hello,
For me this version isn't interesting, i am still looking for fix for these bugs:

http://bugs.winehq.org/show_bug.cgi?id=34650

http://bugs.winehq.org/show_bug.cgi?id=33660

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)

[pinguinpc]

Reporting from Wine 1.7.10, steam still works and other games also works

[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

[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?

[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.

[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>

[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]

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

[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?