Announcement

Collapse
No announcement yet.

Direct3D 9 Support Stands A Chance Of Being Added To Mesa

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

  • Direct3D 9 Support Stands A Chance Of Being Added To Mesa

    Phoronix: Direct3D 9 Support Stands A Chance Of Being Added To Mesa

    For several months now there's been a Direct3D 9 state tracker under development for Mesa that's making some headway and working out for bettering the Wine performance with D3D9 titles rather than using Wine's translation layer to OpenGL. While no official request for pulling the code has been issued, it looks like it might stand a chance of hitting mainline Mesa...

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

  • #2
    Yes, please merge.
    I also have Gentoo ebuilds for wine-d3d9 if someone is interested. I will publish them soon on my website.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      wine-1.7.24-d3dadapter.patch https://gist.github.com/Thermionix/329dddf2bf84d86e6383

      patch generation;
      Code:
      git clone https://github.com/iXit/wine.git
      cd wine
      git checkout d3dadapter9-wip
      git remote add upstream git://source.winehq.org/git/wine.git
      git fetch upstream
      git merge --no-edit upstream/master
      git diff upstream/master..d3dadapter9-wip > d3dadapter.patch
      Arch AUR PKGBUILDs;
      https://aur.archlinux.org/pkgbase/mesa-d3d9-git/
      https://aur.archlinux.org/packages/wine-d3dadapter-git/

      Comment


      • #4
        I'm hesitant on the merge because I'm not sure if there are enough people actively maintaining it. It's one thing if it works, but if it breaks in the future, somebody has to fix it and if it isn't fixed it will have to be taken out.

        Comment


        • #5
          Originally posted by darkbasic View Post
          Yes, please merge.
          I also have Gentoo ebuilds for wine-d3d9 if someone is interested. I will publish them soon on my website.
          please do. fast
          do you have the ebuilds needed for mesa-d3d9 too?

          Comment


          • #6
            Mesa packages in my Ubuntu PPA include it .

            There is no wine package however, so you have to build it yourself or get it from other PPA.

            Comment


            • #7
              This coincide very neatly with the Radeon driver almost getting as fast as Catalyst.
              This is the power of open source, anything can happen if people are willing to work on it.

              Comment


              • #8
                I have read several articles on the state tracker recently and I'd like to check if I'm understanding it right.

                Someone has created a Direct3D implementation which runs upon Gallium. So Wine, rather than converting Windows Direct3D calls to Linux OpenGL ones, it instead converts them to the Linux Direct3D calls, saving a bit of overhead.

                But could these calls be made from Linux directly? Could we have native Direct3D games? Could someone porting a Direct3D game from Windows to Linux, rather than converting to OpenGL, just use this state tracker instead? (Obviously Gallium drivers only)

                Is there any extra overhead compared to OpenGL with Gallium?

                How complex is the Direct3D state tracker? With OpenGL there are functions like glVertex3f, glBindTexture. Are these the sort of functions which the state tracker exposes? Did they create an implementation of every DirectX function?

                When a graphics card supports "DirectX 10", what exactly does this mean? Are the DirectX functions somehow implemented in the card, so a state tracker somehow maps these functions to the card? What does it mean if a graphics card doesn't support DirectX 10 say?

                Sorry for loads of questions - I'm not entirely sure how graphics cards work.

                Comment


                • #9
                  Originally posted by arabek View Post
                  please do. fast
                  do you have the ebuilds needed for mesa-d3d9 too?
                  I have all the needed ebuilds and they worked flawlessly last time I used them. I still didn't publish the ebuilds nor the benchmarks because d3d9 is mainly tested on nouveau and it didn't work very well on radeonsi.
                  Anyway when it worked it was faster than wine-d3dstream (CSMT).
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #10
                    Originally posted by Anthony View Post
                    I have read several articles on the state tracker recently and I'd like to check if I'm understanding it right.

                    Someone has created a Direct3D implementation which runs upon Gallium. So Wine, rather than converting Windows Direct3D calls to Linux OpenGL ones, it instead converts them to the Linux Direct3D calls, saving a bit of overhead.

                    But could these calls be made from Linux directly? Could we have native Direct3D games? Could someone porting a Direct3D game from Windows to Linux, rather than converting to OpenGL, just use this state tracker instead? (Obviously Gallium drivers only)

                    Is there any extra overhead compared to OpenGL with Gallium?

                    How complex is the Direct3D state tracker? With OpenGL there are functions like glVertex3f, glBindTexture. Are these the sort of functions which the state tracker exposes? Did they create an implementation of every DirectX function?

                    When a graphics card supports "DirectX 10", what exactly does this mean? Are the DirectX functions somehow implemented in the card, so a state tracker somehow maps these functions to the card? What does it mean if a graphics card doesn't support DirectX 10 say?

                    Sorry for loads of questions - I'm not entirely sure how graphics cards work.
                    yes
                    yes... and no. it would cause problems as there is only support for oss drivers, unless someone implemented this lib as dual in a sense of use this for oss and use wine gl implementation when non oss driver. that would also bring the world of hurt since blobs would be inferior and at the same time leading developers believe direct3d is the way to go. not to mention it would put linux in low performer class, since oss performance would be max possible. if blobs implemented it, performance would get equal, but at the same time it would deprecate gl on whole lot of fronts
                    no clue about this one.
                    as far as i looked the code it is pretty straight forward
                    not sure about this one in whole

                    Comment


                    • #11
                      Originally posted by justmy2cents View Post
                      yes
                      yes... and no. it would cause problems as there is only support for oss drivers, unless someone implemented this lib as dual in a sense of use this for oss and use wine gl implementation when non oss driver.
                      Also remember that the (official) open source Intel driver does not use Gallium3D. This D3D9 state tracker only has relevance for a limited niche of Wine users. I really hope the performance difference is worth maintaining it in both Mesa and Wine!

                      Now if we instead could standardise a Gallium3D-like low level API we could build low overhead D3D and OpenGl obsolescence layers upon, that would be of great benefit to _both_ driver developers and Wine developers. We could even call it OpenGl 5
                      :-)

                      Comment


                      • #12
                        Hmm.... We can't use S3tc compression or integer textures because of legal fears, but we are ok with a Microsoft API implementation?

                        Not expecting this to be merged. In any case - DX compatibility is "less exciting" now that we have native Steam support.

                        Comment


                        • #13
                          I'm only interested if someone can get this working with binary, non-free drivers. Sure, with this you could get some interesting results with games that may not work terribly well now, but you're shutting out loads of other games, like native games, that require NVIDIA drivers or Catalyst drivers in order to get decent performance.
                          Also, one does have to hope that dx10/11 could be supported at some point, since the winehq mob don't seem too keen on doing that.
                          I'd also like some word on the legal consequences of essentially reverse engineering dx9. Is that what this state tracker is doing?

                          Comment


                          • #14
                            Originally posted by Veto View Post
                            Also remember that the (official) open source Intel driver does not use Gallium3D. This D3D9 state tracker only has relevance for a limited niche of Wine users. I really hope the performance difference is worth maintaining it in both Mesa and Wine!

                            Now if we instead could standardise a Gallium3D-like low level API we could build low overhead D3D and OpenGl obsolescence layers upon, that would be of great benefit to _both_ driver developers and Wine developers. We could even call it OpenGl 5
                            :-)
                            good point. forgot about this

                            standardizing galium for all and then have blob (nvidia, catalyst) loaded on demand if needed ... one could only wish for that and at the same time all drivers would support state trackers like this... hmmm, nah... reality is never perfect

                            Comment


                            • #15
                              Originally posted by OneTimeShot View Post
                              Hmm.... We can't use S3tc compression or integer textures because of legal fears, but we are ok with a Microsoft API implementation?

                              Not expecting this to be merged. In any case - DX compatibility is "less exciting" now that we have native Steam support.
                              1) As you said it's an API not a patented algorithm or anything like that (which shouldn't be patentable in the first place, but that's another discussion).
                              2) Both of your examples are supported by mesa (if you're speaking about s3tc and float textures)
                              3) D3D 10/11 was already merged and just removed because it was unmaintained and not fully working and not because it's a Microsoft API
                              4) Native steam support doesn't mean all games switch to OGL, especially not old games

                              Comment

                              Working...
                              X