Announcement

Collapse
No announcement yet.

Wine's Big Command Stream D3D Patch-Set Updated

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by stefandoesinger View Post
    Well, our (the Wine developers') and the Mesa developers' time is limited. With regards to running d3d9 applications on Mesa we have the following options:
    1. Make Wine work better on all OpenGL implementations.
    2. Make Mesa run all OpenGL applications better.
    3. Write and maintain lots of special code to make Wine run better on Mesa.

    Considering finite resources, we believe 1 is the way to go, and we're helping the Mesa devs with 2. You may disagree and submit code to either project to implement 3. But don't think it's a conspiracy when we disagree with you about what to do with our time.


    I have MESA and Wine compiled by me with the D3D9 state tracker. I just don't know why all the rest they don't. And they need to do the same as me. I didn't ask you why you don't work to improve the state tracker. We have seen what a single person can do if he is technologically and ethically right (a state tracker). So i don't really want to ask anything about your time. There are distros and individuals responsible to have those packages in their repository.

    Comment


    • #42
      Originally posted by stefandoesinger View Post
      The easy work is done. The hard part that separates a proof of concept from code that is stable and maintainable in the long term is remaining. In other words, following the 80/20 rule, 80% of the work still needs to be done.

      A good start would be to quantify the performance difference between wined3d and gallium-nine with reproducible benchmarks and then isolate where the performance difference is coming from. And that means not just "it reduces overhead, so it's faster", but something like "There's CPU-side overhead in module X, and GPU-side overhead because shader instructions A, B and C are inefficiently handled by module Y".

      If it turns out that there's a fundamental advantage to a gallium state tracker, and that it's not just working around some bugs in Mesa and Wine that could be fixed with e.g. a better GLSL compiler or adding one or two focused GL extensions to support some d3d-isms better the next task is finding a stable API exposed by gallium-nine and used by Wine.

      Matteo has done some testing with gallium-nine on r600g. If I remember correctly, he saw a moderate performance gain (~15% or something), but attributed most of that to insufficient optimization in the driver's GLSL compiler. I'll ask him to make sure my memory serves me right.

      Thats weird, i have mostly a 2x gain with i5 and 3x+ with Core2. This thing offloads the Cpu dramatically, and some advanced shaders that are not even run with Wine, are now work. Its like a GLSL=disabled plus Threaded-Optimisations plus+++ all together.

      Comment


      • #43
        Gallium nine still ALIVE!

        I wrote small article about it, it work with mesa 10.0 and lastest wine. DEVELOPERS NEEDED So, if you want help with some small patch, some improvment, fix, everything is welcomed!

        I'll try keep it alive, any help appriciated!

        https://ixit.cz/faster-wine-games-wi...-gallium-nine/

        Comment


        • #44
          Originally posted by stefandoesinger View Post
          Probably because you misspelled it. It should be CSMT, not SCMT.
          Yup, CSMT, certainly, misspelled only here in my post. Maybe I should have that <enabled> in quotes? ))

          Originally posted by artivision View Post
          Thats weird, i have mostly a 2x gain with i5 and 3x+ with Core2. This thing offloads the Cpu dramatically, and some advanced shaders that are not even run with Wine, are now work. Its like a GLSL=disabled plus Threaded-Optimisations plus+++ all together.
          Please, please, may you tell me how? I cannot do that.

          Comment


          • #45
            Originally posted by artivision View Post
            Thats weird, i have mostly a 2x gain with i5 and 3x+ with Core2. This thing offloads the Cpu dramatically, and some advanced shaders that are not even run with Wine, are now work. Its like a GLSL=disabled plus Threaded-Optimisations plus+++ all together.
            This is my opinion as well, and i don't need tests to be convinced...

            A d3d state tracker can make wine extremely efficient for games. Granted, it is only for gallium and there may be patent fears etc. But i don't believe it requires much work.

            The way i see things, Wine and Crossover developers have certain target groups and Linux users don't rank highly on that list... How many times has it happened? A project that could be used to improve Wine for Linux not getting accepted?

            Wine prefers the Mac platform, it is obvious. I am willing to bet that if Apple had gone the gallium3d way, Wine would support d3d trackers ASAP.

            I didn't want to say this earlier, because i wanted to read Stefan's opinion first. And he just provided us with excuses that have no technical merit at all.

            No one asked them to develop or maintain a d3d9 state tracker. We just asked the option to use it to be included officially... It is not much work and it could be a compile time option.

            I am pretty sure MESA devs wouldn't mind to include it, if there was a use for it. And the only use for it would be if WINE supported it. So this is a chicken and egg problem, WINE devs won't support it because it is not for Apple systems with excuses like "it needs maintainance", while MESA devs can't mainline it if there is no software using it...

            Comment


            • #46
              Originally posted by OnioWoess View Post
              Well, I dunno what I'm doing wrong but I see almost no difference yet between standard wine (1.6) and this one (1.7.10 patched), clean install both on Linux Mint XFCE Petra Also, on example of these games running under wine and under winXP: Xonotic, Killing Floor and Half Life 2, I still have huge difference in their performance and loss approx half of FPS under wine + freezes. Added HKCU/Software/Wine/Direct3D/SCMT/="enabled" key - it changes nothing. Tested on my old PC with nVidia GTS450 1Gb on 319 drivers, AMD X2 4400+ 1750 Mhz

              you wont gain much (if at all) because of your weak old CPU.. dual core and low frequency.

              Comment


              • #47
                Originally posted by xpander View Post
                you wont gain much (if at all) because of your weak old CPU.. dual core and low frequency.
                Ahh. You wanna say that this tricks with wine works only for modern hardware and could give a boost only comparable to the previous poor results on it .
                Therefore, no chance to get same framerate even in HL2 then, which I have in Windows (wine - 40-160 winXP - 200-300)...

                I could test it with my another PC, though, but I hoped it'll give a second chance to my old one. Sigh )
                Last edited by OnioWoess; 01-13-2014, 05:43 AM.

                Comment


                • #48
                  Originally posted by OnioWoess View Post
                  Ahh. You wanna say that this tricks with wine works only for modern hardware and could give a boost only comparable to the previous poor results on it .
                  Therefore, no chance to get same framerate even in HL2 then, which I have in Windows (wine - 40-160 winP - 200-300)...
                  well according to my tests you need a good dualcore cpu at least to see some improvements
                  quadcore is even better

                  probably you can get some improvements if you kill all other tasks on your OS... so nothing else access 1 of your cores.

                  but seriously that old athlon x2 is super old.

                  Comment


                  • #49
                    Valley Benchmark in Wine

                    https://www.youtube.com/watch?v=8r_dSJ6uwms

                    Simple Screen Recorder kills some performance also though, but the point is still valid.. 2x perf boost with CSMT enabled.

                    Comment


                    • #50
                      Originally posted by TemplarGR View Post
                      The way i see things, Wine and Crossover developers have certain target groups and Linux users don't rank highly on that list... How many times has it happened? A project that could be used to improve Wine for Linux not getting accepted?

                      Wine prefers the Mac platform, it is obvious. I am willing to bet that if Apple had gone the gallium3d way, Wine would support d3d trackers ASAP.

                      I didn't want to say this earlier, because i wanted to read Stefan's opinion first. And he just provided us with excuses that have no technical merit at all.

                      No one asked them to develop or maintain a d3d9 state tracker. We just asked the option to use it to be included officially... It is not much work and it could be a compile time option.

                      I am pretty sure MESA devs wouldn't mind to include it, if there was a use for it. And the only use for it would be if WINE supported it. So this is a chicken and egg problem, WINE devs won't support it because it is not for Apple systems with excuses like "it needs maintainance", while MESA devs can't mainline it if there is no software using it...
                      easy to speak like that when you're not the developer. each developer has its own plans for his baby. if you need to go trough hoops and loops for whims,... not fun.

                      (i'm not wine developer, so i might be completely out of base. if so i apologize. this is bystanders viewpoint)
                      fail nr.1) state tracker d3d9 only works with OSS drivers, not with blobs. you need 2 codebases for same thing in order to achieve the goal of wine. and the result is even worse, each time you get bug report you need to check the 2 codepaths, which would lead to lots of false positives and noise for wine developers since you can bet both legs that error reports will fly in their Issues.
                      fail nr.2) most projects like that are temporary where maintainers get lost and whole bugs and problems fall on developers who never made anything other than just approve code to be part of their project
                      fail nr.3) let's say this thing works well and developers start using this for games just to spare them selves porting troubles... that is one shitload of excuses for MS to suddenly throw some punches in order to discredit linux gaming. if there is no directx option, developers that write for linux must use established and safe OpenGL engine. this is not the question if MS has any legal basis, sometimes simply starting long term losing battle can prove as victory since other party can't afford battle long enough to win.

                      then again nothing would prevent anyone to simply host patched wine where they simply abstract interface for function calls like for example fuse does and enable option "UseStateTracker=true". by default you simply initialize by setting wine methods as abstraction, but if option is set, then you simply set state tracker methods. if this wine version proves successful you can bet mesa/galium developers will see incentive to include tracker by default

                      Comment

                      Working...
                      X