Announcement

Collapse
No announcement yet.

Wine Developers Not Yet Convinced By Direct3D 9 In Mesa's Gallium

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

  • Wine Developers Not Yet Convinced By Direct3D 9 In Mesa's Gallium

    Phoronix: Wine Developers Not Yet Convinced By Direct3D 9 In Mesa's Gallium

    While Direct3D 9 support in Gallium3D is moving along and will quite likely be merged to mainline Mesa, the Wine developers aren't yet interested in accepting patches to allow this Gallium3D state tracker to be used for increasing the performance of D3D9-using Windows applications...

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

  • #2
    It's time to fork I think.

    Comment


    • #3
      Understandable decision

      Originally posted by phoronix View Post
      Phoronix: Wine Developers Not Yet Convinced By Direct3D 9 In Mesa's Gallium

      While Direct3D 9 support in Gallium3D is moving along and will quite likely be merged to mainline Mesa, the Wine developers aren't yet interested in accepting patches to allow this Gallium3D state tracker to be used for increasing the performance of D3D9-using Windows applications...

      http://www.phoronix.com/vr.php?view=MTgzOTc
      I don't really disagree with the Wine and Crossover development team over this. Merging these patches would make Wine more dependent on the Gallium3D drivers and the possibility of new regressions or issues with existing games.

      I'm curious what kind of performance gain you'll realize by using native Direct3D as oppsed to the Command Stream patchset, which is something I've used in my Crossover 14 and patched versions of Wine 1.7.24 via PlayOnLinux.

      Comment


      • #4
        yes

        Originally posted by zxy_thf View Post
        It's time to fork I think.
        wine is only for mac users now

        Comment


        • #5
          Originally posted by zxy_thf View Post
          It's time to fork I think.
          that would be nuts, instead let gallium mature and the d3dstate tracker improve, the should code it on a way that can be enabled at runtime and maybe create some better interfaces on the wine side.

          Comment


          • #6
            I don't know when I'll find myself using Gallium3D, but if I ever am, I'm sure It'll be easy installing from the AUR.

            Comment


            • #7
              Having worked (for a brief time) on a few patches for WineD3D about 9 or 10 years ago and spoken in person with Henri and Stefan, I can appreciate the gargantuan effort that had gone into its development. These guys have really gained a very deep understanding of both Direct3D and OpenGL.

              Let me just say this: I can totally understand why they would not want to rush into something like this. It is so easy to think "Oh, DirectX9 state tracker?! Great, let's move to that" but when you realize the sheer complexity of the undertaking, and look at it from their point of view - the man hours that have already gone into well tested code - it is totally natural that they would not be quite so receptive to such a big change happening so quickly underneath their feet, let alone the inconsistencies introduced by bringing in something that doesn't exactly fit with the way the current API works.

              All I'm asking is, try to empathize with why they might not want to "just switch it".

              Final thought: Sometimes it is far easier to finish work on something big which is well tested than to throw it to one side and bend the metal so that a "new piece" fits. No doubt it will become part of wine - but give the guys time to assimilate the new information. What if there is a D3D10 state tracker that comes along? How would /that/ then fit into the picture.. etc, etc.

              Comment


              • #8
                Originally posted by philcostin View Post
                Let me just say this: I can totally understand why they would not want to rush into something like this. It is so easy to think "Oh, DirectX9 state tracker?! Great, let's move to that" but when you realize the sheer complexity of the undertaking, and look at it from their point of view - the man hours that have already gone into well tested code
                Yep, it can be annoying when someone puts thousands of hours into a project which gets destroyed by another, smaller project (in terms of compability and performance).

                If they don't want to merge GalliumNine, fuck them, like someone has said, time to fork

                Comment


                • #9
                  Well Wines D3D9 implementation is more complete then the GalliumNine one.

                  To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware.
                  Would be interesting to see if this would give as much boost as GalliumNine.

                  Comment


                  • #10
                    Originally posted by zxy_thf View Post
                    It's time to fork I think.


                    Originally posted by ObiWan View Post
                    Would be interesting to see if this would give as much boost as GalliumNine.
                    When, like 3 years from now? They've been working on CSMT for years now and its been in CrossOver for a while now. Didn't they say they plan to scrap CSMT and make a new improved something?

                    Yea no I'm going to continue to use patched versions of wine that have gallium and CSMT in it.

                    Comment

                    Working...
                    X