Announcement

Collapse
No announcement yet.

Direct3D Performance Improvements Coming To Wine

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

  • #41
    Originally posted by artivision View Post
    Third, emulation will be always inferior, even against an inferior driver with an inferior state_tracker, who told you that can be faster?
    WINE - Wine Is Not an Emulator

    Its the name of the project so I shouldn't have to say any more. But just to clarify Valve is using a similar technique to *translate* the D3D api to OpenGL calls and have publicly released stats showing that in some cases it has resulted in games running faster.

    Comment


    • #42
      Originally posted by ninez View Post
      You didn't say anything that i mentioned above eh? lololol... So you didn't claim Wine was a linux open source program? (you did). You didn't claim that "this patch doesnt't do anything"?? (you did) ....lololol... You didn't claim that "hey must not control Wine any more"?? lololol. (you did)... And your above comment is even worse / more hilarious; You're being ridiculous and making wild accusations about people that you don't even know AT ALL - Saying they are "using authority to harm others" and "boycotting". It's borderline conspiracy theory and certainly does not reflect reality within the project at all. You've been huffing solvents or smoking crack to come to your conclusiobns...seriously.

      it just isn't worth merging, at this point (it hasn't even gone through the typical wine review process at all - but hey, with all of your expertise, psychic abilities to extract the wine develpoers && Codeweavers motivations - you know better, of course...) AND they may not want that patch over some platform specific stuff -> unless they were convinced to / high enough demand... The Wine-patches review process can be rather thorough / time-consuming / rigorous and it isn't uncommon to see more invasive patchsets take some time to be merged. It will also depends on a number of other factors; so saying "they are using authority to harm others" and "boycotting" is just a bunch of asinine nonsense, that only a village idiot would come up with and peddle as fact. <which is exactly what you are doing>..

      On your third point; I never claimed emulation was better did I?? Wtf are you even going on about, really? ... I said it was an improvement over normal wine (that is bound to wineserver) which is true...so seriously, piss off with this nonsensical babble.

      When did i mock someone for writing crappy because of using their non-native tongue in this thread? - sure, i could of mocked someone for many things; but even if that was the case; oh well, cry me a river or grow some thicker skin. It also should be noted that i could care less about perfect grammer on Phoronix forums, pal - So, if you want an award - here you go - you're a real "winner".

      On point 5; good for you! But all that i see is someone complaining like a little baby. i could care less about how amazing you think you are and how "big" your contributions would be, *if* you chose to do so. ~ You're not fooling anyone; you're just being a pretentious narcissistic asshat. Lastly, who told me it was faster? ... Moving busy/taxing calls out of Wineserver almost always ends up in performance improvements, that is just a fact, since wineserver is not multithreaded. Wineserver is probably the biggest bottleneck in Wine, by having dedicated threads (for these kind of calls) instead of relying on Wineserver, you avoid a lot performance problems in Wine, not all of them - but some pretty significant ones, for sure.


      Firs of all, are you really a simple Phoronix reader and not a masked developer from CodeWeavers? Maybe you pretend or you just lack knowledge. A state_tracker is portable. With a simple patch you can add it to Linux Catalyst for example, like a fake libD3D32.dll, or to OSX. Their problem is that they don't want something that they don't control. I didn't say that their patch is useless, the time showing this and the claims about it are wrong. You may see a difference to some games, if you have a SandyBridge with 9.5dmips/mhz per core, but for a Core2duo with 4.5dmips/mhz will be loss anyway. Also graphics inefficiencies will not go away. Anyway ToGLSL is emulation because during this you don't have 1 to 1 translation, so you need to emulate the different parts, and it is slow. At the end lets drop the subject, Wine emulation will die soon, so what is the point?

      Comment


      • #43
        Originally posted by tarceri View Post
        WINE - Wine Is Not an Emulator

        Its the name of the project so I shouldn't have to say any more. But just to clarify Valve is using a similar technique to *translate* the D3D api to OpenGL calls and have publicly released stats showing that in some cases it has resulted in games running faster.

        Valve's source engine is made with D3D to OGL in mind, like Unigine. Doesn't have D3D code that needs emulation, only what can be done 1 to 1 during translation to GLSL.

        Comment


        • #44
          Originally posted by artivision View Post
          A state_tracker is portable. With a simple patch you can add it to Linux Catalyst for example, like a fake libD3D32.dll, or to OSX.
          State trackers will not work with Catalyst. State trackers only work with Gallium based drivers. I don't think you understand how the state trackers work.

          Originally posted by artivision View Post
          Anyway ToGLSL is emulation because during this you don't have 1 to 1 translation
          Very few translations of anything including human languages are 1 to 1 but they are still translations.

          Originally posted by artivision View Post
          so you need to emulate the different parts, and it is slow.
          Your claims are that performance will be 60% of D3D max but you have no evidence at all to backup these claims. Valve published stats showing improved performance.

          Comment


          • #45
            i call bull shit on all of this 60% to 100% faster my ass wine has too many layers and broken api's

            Comment


            • #46
              Originally posted by tarceri View Post
              State trackers will not work with Catalyst. State trackers only work with Gallium based drivers. I don't think you understand how the state trackers work.



              Very few translations of anything including human languages are 1 to 1 but they are still translations.



              Your claims are that performance will be 60% of D3D max but you have no evidence at all to backup these claims. Valve published stats showing improved performance.


              Modern drivers (all today's drivers), they have a unified synthesizer and state_trackers for different apis. With windows drivers libd3d32.dll and libogl32.dll. If a third api shows up "super3d lets say" they just add a libs3d32.dll. With this state_tracker and the the 10/11 one, the same can be done for sure, with all drivers and a simple patch.

              Comment


              • #47
                Originally posted by artivision View Post
                Firs of all, are you really a simple Phoronix reader and not a masked developer from CodeWeavers? Maybe you pretend or you just lack knowledge. A state_tracker is portable. With a simple patch you can add it to Linux Catalyst for example, like a fake libD3D32.dll, or to OSX. Their problem is that they don't want something that they don't control. I didn't say that their patch is useless, the time showing this and the claims about it are wrong. You may see a difference to some games, if you have a SandyBridge with 9.5dmips/mhz per core, but for a Core2duo with 4.5dmips/mhz will be loss anyway. Also graphics inefficiencies will not go away. Anyway ToGLSL is emulation because during this you don't have 1 to 1 translation, so you need to emulate the different parts, and it is slow. At the end lets drop the subject, Wine emulation will die soon, so what is the point?
                No, not a CodeWeavers guy, although I do interact with some of them and know a few wine developers, as well.... Okay, enough with your speculation about people's intentions that *you do not know*; either cough up some documentation / mailing list logs, etc that explicitly show that Codeweavers/Wine Developers intentions are how you say (or rather, how you nastily present them)... that shows thaty they are "boycotting" and "using authority to harm others" or SFTU, It's that simple... Seriously! - You are literally just talking shit / slandering people... Next, stop rehashing this nonsense about what this patch doesn't solve -> It's not supposed to solve problems that it wasn't designed to solve -> it's supposed to solve the bottleneck of using Wineserver, with has to do with multithreading (or lack there of, not all of this hoopla coming out of your mouth about other things)...

                Also, You are wrong about Wine dying soon. Very much, not likely to happen. It's used in Commercial products (by several companies, including in H/W) and a big part of CodeWeaver's business... Maybe you think it will be dead because of native gaming or something like that (i don't know) but that's pretty limited thinking, if that is the case.

                also, the likely hood of the state_tracker being used on other platforms (other than linux) is about ZERO, portable or not (which i am not even convinced they aare, and no; therefore there would absolutely no reason for these developers to add the functionality in Wine - i won't take your word for it. citations, or don't bother talking about it anymore). And as you pointed out - It would be needed to added to all of the GFX driver's on each platform. <so, yeah, as of now - it's non-portable, other than in theory>... and again, ithasn't gone through rigorous testing, nor the review process, nor would anyone who pays any attention to, or is aware how Wine development works, would actually expect that it would be merged...
                Last edited by ninez; 09-06-2013, 09:57 AM.

                Comment


                • #48
                  Originally posted by artivision View Post
                  Modern drivers (all today's drivers), they have a unified synthesizer and state_trackers for different apis. With windows drivers libd3d32.dll and libogl32.dll. If a third api shows up "super3d lets say" they just add a libs3d32.dll. With this state_tracker and the the 10/11 one, the same can be done for sure, with all drivers and a simple patch.
                  My point is you are saying that the Gallium state tracker can simply be applied to any driver. The state tracker would still need to be rewritten to use whatever the equivalent api to the gallium api for that driver is. As far as I know none of those api's are publicly documented.

                  Comment


                  • #49
                    Originally posted by LinuxGamer View Post
                    i call bull shit on all of this 60% to 100% faster my ass wine has too many layers and broken api's
                    I call bullshit on your nick!

                    Comment


                    • #50
                      Originally posted by artivision View Post
                      Lies above lies.

                      This patch doesn't do anything. When you have a game that is peaky with threads and doesn't let you have multithreading, now you can partially do it. So you can raise your FPS to some games with CPU bottleneck problems. But unfortunately this will help only if you have a 2-core Sandybridge+. Because if you have a Core2-duo, running two compilers and an emulator (HLSL_source---to_ASM---to_GLSL_source---to_GLSL_bytecode), that will be still a CPU bottleneck.
                      Yea the reality is that this requires you to have a Quad core CPU with at least 1 core idle. So if you have a dual core CPU and the game makes use of those two cores, you won't see much of a performance increase.
                      This also doesn't do anything with D3D to OGL graphics inefficiencies. Really many D3D games can only perform a 60% with emulation, wile they waste the entire GPU. This is not fixable, because the two APIs are different. In some point OGL is like a flipped down(reversed) D3D.
                      The idea is the GPU is sitting idle, waiting for the CPU. If the CPU is busy with other things like a game, then the GPU sits idle. Since there's a lot that goes from D3D to OGL, having it thrown onto an idle CPU core would reduce GPU idle.
                      When a working D3D_state_tracker for MESA is ready, then you hear farts coming from all directions. Those CodeWeavers something, they magically double their performance, wile Chronos(outer space) group announces D3D_Compatibility_Extensions for OGL4.4. Of course the first is a lie, and the second is a trash. That's because you probably cannot run MS_D3D_Compiler with this, you still need an OGL based Compiler for HLSL_source. Its basically a faster and more efficient ToGLSL. So we need work again.
                      Clearly the DX9 state tracker would offer the best performance increase. But some reasons people overlook the fact that codeweavers is behind WINE. So when you offer a performance increase that only works in Linux, and for that matter not proprietary drivers from AMD, Nvidia, and Intel, you can see this is more of a business move then anything else. What would be the big deal to support the DX9 state tracker, when it could be an option to enable it?

                      Another alternative is using OpenCL to quickly translate the D3D to OGL within the graphics card. Again, it would slow down games, but not by much. It would still be faster using the DX state tracker.

                      Comment

                      Working...
                      X