Announcement

Collapse
No announcement yet.

Gallium3D Direct3D 9 For Wine Revived, Again

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

  • #41
    WINE is free Winapi implementation, not free Directx implementation.

    As such, I see no problem with Dx state tracker usage over Gallium, skipping whole Dx-OpenGL overhead and plugging directly into graphics driver.


    But also remember, how Microsoft has suspended OpenGL? In Dx versions 1-3, the OpenGL was plugged into Dx HAL, not into driver level. So GL performance will always be lower than raw Dx intermediate solely due to the overhead translation.
    By skipping the overhead of GL-Dx translation, Wine could gain really good performance on machines with Gallium available.


    But then, the Dx redistributables are required to be installed into Wine userspace.
    MS can easily create a method to block such usage, because using Dx as of EULA, apart from prohibiting reverse engineering, allows MS to reserve rights in the future. As such it can easily block the usage of the module by disallowing its installation and usage outside of ms-certified environments.


    I think we have exactly the same situation as with Reiser.
    In either case, the patches are better off maintained externally for some time to prevent the case of suddenly disappearing developer.
    They could also be useful to measure the OpenGL-Dx translation overhead!

    Comment


    • #42
      Originally posted by Espionage724 View Post
      Are you trying to make a point, or promote NVIDIA's proprietary driver? I fail to see any reason for the latter in this thread...

      My only problem with fglrx and Wine was Guild Wars 2 and osu!, and both seem to work great for me now. On radeonsi, both games also worked, but were slightly slower. Can't say I care how they perform on NVIDIA since I don't own such hardware (and won't for political reasons). But giving the impression Wine is next to useless on AMD in-comparison to NVIDIA just isn't true.
      The point is nvidia privative driver driver offer much performance and compatibility than AMD/ATI, this situation can consulted on wineappdb for many apps

      AMD/ATI can be used but have more problems with wine than nvidia, compatibility much reduced, performance much reduced and this situation not change in short time because only free information (lack of GCN hardware information compared to privative) not solve, AMD must be compromise more seriously (resources) with opensource community especially

      A major problem in games especially is, in mayor part of games of 2012 and before appears (Nvidia meant be to played) this is a serious problem, and that situation have since 10 years


      I can test some titles since 2009 on my blog (I testing both hardware)

      http://gamesonwine.blogspot.com

      or on my youtube channel

      https://www.youtube.com/user/mrdeathjr28



      Comment


      • #43
        Originally posted by TemplarGR View Post
        As for me creating a fork of Wine with the d3d9 tracker support, because that is what you are suggesting, it is quite a stupid proposal. There is absolutely no need for that. You shouldn't create a fork just to use a patchset. If a distro wants the d3d9 state tracker, it can enable it. The problem is that this won't lead to its universal use and as such interest in improving the d3d9 state tracker will dissappear, just as it happened with the d3d10/11 state tracker.
        The problem isn't technical, but more political. We know the D3D9 state tracker can be faster and more stable, but isn't implemented because of cross compatibility with MacOSX and non Gallium3D based drivers. But at this point I think a simple patch for Mesa and Wine is enough. If enough people use it, then Wine developers may change their minds and mainline it.

        Comment


        • #44
          Originally posted by Dukenukemx View Post
          The problem isn't technical, but more political. We know the D3D9 state tracker can be faster and more stable, but isn't implemented because of cross compatibility with MacOSX and non Gallium3D based drivers. But at this point I think a simple patch for Mesa and Wine is enough. If enough people use it, then Wine developers may change their minds and mainline it.
          We need a hero(someone with both the skills and drive) to set up and make this a reality and write the patch and spin a modified version of Wine in a ppa/repository for people to try.

          Comment


          • #45
            I'm a little late to the party and not well informed on wine, but lets see if I have this right.

            - When I install and run a game under wine, it basically translates directx to opengl.
            - This patch would enable native directx runtime, meaning no overhead but...
            - Licensing issues if Microsoft wants to be... well, Microsoft and screw everyone over

            If all of the above is true, would we not be able to say:
            1) Install a game through wine
            2) This patch thingy would be used to translate Directx straight to OpenGL
            3) No need for Directx emulation after that

            Or am I dreaming? Because it'd be a powerful tool for anyone who wants to port a Windows game to Linux. Run it through this system once for a working example, and then they would only need about a month for full optimization. (depending on the team size) And sorry for my poor knowledge of terms and such.

            Comment


            • #46
              Originally posted by dh04000 View Post
              We need a hero(someone with both the skills and drive) to set up and make this a reality and write the patch and spin a modified version of Wine in a ppa/repository for people to try.
              Maybe who ever is responsible for this PPA can add support for the DX9 state stracker? Oibaf drivers are very popular, so maybe he can add the DX9 state tracker to his drivers?

              Originally posted by profoundWHALE View Post
              I'm a little late to the party and not well informed on wine, but lets see if I have this right.

              - When I install and run a game under wine, it basically translates directx to opengl.
              - This patch would enable native directx runtime, meaning no overhead but...
              - Licensing issues if Microsoft wants to be... well, Microsoft and screw everyone over

              If all of the above is true, would we not be able to say:
              1) Install a game through wine
              2) This patch thingy would be used to translate Directx straight to OpenGL
              3) No need for Directx emulation after that

              Or am I dreaming? Because it'd be a powerful tool for anyone who wants to port a Windows game to Linux. Run it through this system once for a working example, and then they would only need about a month for full optimization. (depending on the team size) And sorry for my poor knowledge of terms and such.
              There are three methods for running Direct3D games in Wine.

              1) Current stable method, which is a slow D3D -> OpenGL process.
              2) New D3D which isn't implemented yet into Wine, but basically multi-threads D3D-> OpenGL for a huge speed boost.
              3) Use a state tracker which actually gives native DX9 to Open Source drivers. Would be the fastest method since there's no conversion process of D3D->OpenGL, and would experience less bugs.

              Christoph Bumiller of Nouveau originally developed the DX9 state tracker, and got it damn near working perfectly, including even in wine. It was shrugged off and forgotten, or at least we thought until okias revived it, and it apparently kicks ass. But this only works with Open Source drivers, and not even the Intel open source driver. Just Gallium3D and Nouveau drivers.

              As for legal issues with Microsoft, there isn't any, at least not yet. Nobody knows if implementing a native DX9 state tracker is breaking any laws, but nobody wants to incur the wrath of Microsoft. Even if it's not illegal, nobody wants to spend the legal fees to fend them off. Too much of a grey area.

              But it's probably not the main reason you won't see this in Wine. Their reasoning is that it's too much extra work for something only a few will be able to use. Even though Intel graphic cards aren't really for gaming, and AMD open source drivers are nearly as good as proprietary. The exception is Nvidia where the proprietary is really really good.

              Comment


              • #47
                I thought there was some under-developed gallium3d Intel driver too, but Intel didn't want to play ball with their competitions tech since it was NIH, and in their defense at the time Gallium blew chunks compared to their own stack.

                Comment


                • #48
                  Would be possible to implement the state tracker in non-Gallium3D drivers?

                  Comment


                  • #49
                    Originally posted by Dukenukemx View Post
                    Maybe who ever is responsible for this PPA can add support for the DX9 state stracker? Oibaf drivers are very popular, so maybe he can add the DX9 state tracker to his drivers?



                    There are three methods for running Direct3D games in Wine.

                    1) Current stable method, which is a slow D3D -> OpenGL process.
                    2) New D3D which isn't implemented yet into Wine, but basically multi-threads D3D-> OpenGL for a huge speed boost.
                    3) Use a state tracker which actually gives native DX9 to Open Source drivers. Would be the fastest method since there's no conversion process of D3D->OpenGL, and would experience less bugs.

                    Christoph Bumiller of Nouveau originally developed the DX9 state tracker, and got it damn near working perfectly, including even in wine. It was shrugged off and forgotten, or at least we thought until okias revived it, and it apparently kicks ass. But this only works with Open Source drivers, and not even the Intel open source driver. Just Gallium3D and Nouveau drivers.
                    Nouveau is Gallium3D. I'm working on getting it going on Intel too, utilising the ilo Gallium3D driver. (Yes, this should work even while using the Classic i965 DRI driver since gallium-nine uses the gallium pipe-loader which works the same way as the EGL driver - which you can select at run-time with EGL_DRIVER)

                    As for legal issues with Microsoft, there isn't any, at least not yet. Nobody knows if implementing a native DX9 state tracker is breaking any laws, but nobody wants to incur the wrath of Microsoft. Even if it's not illegal, nobody wants to spend the legal fees to fend them off. Too much of a grey area.

                    But it's probably not the main reason you won't see this in Wine. Their reasoning is that it's too much extra work for something only a few will be able to use. Even though Intel graphic cards aren't really for gaming, and AMD open source drivers are nearly as good as proprietary. The exception is Nvidia where the proprietary is really really good.
                    I suspect the issue is much more as has been suggested above re. MacOSX support... the only important Linux drivers this can't support are the proprietary ones...

                    Comment


                    • #50
                      Originally posted by Dukenukemx View Post
                      Maybe who ever is responsible for this PPA can add support for the DX9 state stracker? Oibaf drivers are very popular, so maybe he can add the DX9 state tracker to his drivers?



                      There are three methods for running Direct3D games in Wine.

                      1) Current stable method, which is a slow D3D -> OpenGL process.
                      2) New D3D which isn't implemented yet into Wine, but basically multi-threads D3D-> OpenGL for a huge speed boost.
                      3) Use a state tracker which actually gives native DX9 to Open Source drivers. Would be the fastest method since there's no conversion process of D3D->OpenGL, and would experience less bugs.

                      Christoph Bumiller of Nouveau originally developed the DX9 state tracker, and got it damn near working perfectly, including even in wine. It was shrugged off and forgotten, or at least we thought until okias revived it, and it apparently kicks ass. But this only works with Open Source drivers, and not even the Intel open source driver. Just Gallium3D and Nouveau drivers.

                      As for legal issues with Microsoft, there isn't any, at least not yet. Nobody knows if implementing a native DX9 state tracker is breaking any laws, but nobody wants to incur the wrath of Microsoft. Even if it's not illegal, nobody wants to spend the legal fees to fend them off. Too much of a grey area.

                      But it's probably not the main reason you won't see this in Wine. Their reasoning is that it's too much extra work for something only a few will be able to use. Even though Intel graphic cards aren't really for gaming, and AMD open source drivers are nearly as good as proprietary. The exception is Nvidia where the proprietary is really really good.
                      Do you think it would be possible, or even worth it, if say a program installed through Wine that used Directx had all of that Directx->OpenGL? So then at runtime it would be running OpenGL(created from Directx) with no overhead.
                      In short:
                      Wine->Install; Directx->OpenGL
                      Wine->Emulate Win32 program; OpenGL

                      Is that sort of thing possible? I have a feeling that we'd need the source code to make a major modification like that.

                      Comment

                      Working...
                      X