Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Wine 1.7.10 Has AVI Compressor, Task Scheduler

  1. #1
    Join Date
    Jan 2007
    Posts
    15,135

    Default Wine 1.7.10 Has AVI Compressor, Task Scheduler

    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

  2. #2
    Join Date
    Dec 2013
    Location
    Prague
    Posts
    4

    Default

    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)

  3. #3
    Join Date
    Jun 2009
    Posts
    168

    Default

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






  4. #4
    Join Date
    Jun 2009
    Posts
    168

    Default

    Quote Originally Posted by Pepes View Post
    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


  5. #5
    Join Date
    Dec 2010
    Location
    Over there somewhere
    Posts
    239

    Default

    Quote Originally Posted by pinguinpc View Post
    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?

  6. #6

    Default

    Quote Originally Posted by Larian View Post
    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.

  7. #7
    Join Date
    Jun 2009
    Posts
    168

    Default

    Quote Originally Posted by stefandoesinger View Post
    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>


  8. #8

    Default

    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.

  9. #9
    Join Date
    Jun 2009
    Posts
    168

    Default

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




  10. #10

    Default

    Quote Originally Posted by AnonymousCoward View Post
    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •