Announcement

Collapse
No announcement yet.

Direct3D In Gallium3D Suffers Bit-Rot, Now Disabled

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

  • Direct3D In Gallium3D Suffers Bit-Rot, Now Disabled

    Phoronix: Direct3D In Gallium3D Suffers Bit-Rot, Now Disabled

    The Direct3D 10/11 state tracker for Mesa's Gallium3D has basically fallen into an unfortunate and unusable state...

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

  • #2
    ya this code would have been meaningfull if someone was using gallium for a windows driver (as it was its intended purpouse when designed) but nobody ever implemented it as such. i would have though reactos would find much value in it, or maybe if intel would use gallium for their driver they could use it as their windows driver too and share codebase between the linux and wondows drivers (you know, like how amd catalyst and nvidia blobs do) but then, you would have a dx10-11 implementation, great, but nothing really requires that. most things require a dx9 driver though, and we dont have one of those for gallium.

    the dx10-11 driver while im shure was capable of demo programs, could not posssibly be all that functional and capable, i mean, look at how slow mesa is to develop, how could tungsten just write up a full capable 3d api on the side that was competative.

    Comment


    • #3
      [Seinfeld]That's a shame...[/Seinfeld]

      There are more pressing issues for gallium3d, like getting intel onboard and getting the godd@mned (yeah, it really is) vdpau state tracker up to snuff, getting radeonsi done, various nouveau fixes, etc. You have to build the base of the pyramid first..

      Comment


      • #4
        Yeah. Unfortunate, but not a surprise. I'd only seen a handful of commits to it over the last months. On the upside, a less politically charged modern graphics library to replace the crufty crap that is OpenGL actually is in the works.

        Comment


        • #5
          Originally posted by elanthis View Post
          Yeah. Unfortunate, but not a surprise. I'd only seen a handful of commits to it over the last months. On the upside, a less politically charged modern graphics library to replace the crufty crap that is OpenGL actually is in the works.
          What is that?

          Comment


          • #6
            Should you care about this Direct3D state tracker for Gallium3D (in hopes of restoring work on it), pass --enable-d3d1x when building Mesa.
            No, actually the commit disables this flag and basically hard codes it to disabled. If you wanted to work on the code, you'd revert the commit and then use the (again available) --enable-d3d1x flag.

            Comment


            • #7
              Originally posted by jayrulez View Post
              What is that?
              That's called "elanthisSpeculationGL FX (TM)" v2.0

              Comment


              • #8
                Originally posted by mattst88 View Post
                No, actually the commit disables this flag and basically hard codes it to disabled. If you wanted to work on the code, you'd revert the commit and then use the (again available) --enable-d3d1x flag.
                ....
                The programmer's way of saying... Buzz off, I know it's broken and I don't want your bug reports anymore... I'd think those bug reports would be valuable to somebody who would eventually start working on it, so I don't know what the big deal is about "tired of seeing bug reports" about it. They don't know how to use bug filters over there? IMO, every bug report is valuable and they should be kept / accepted until somebody gets around to working on it..

                Comment


                • #9
                  Originally posted by Sidicas View Post
                  ....
                  The programmer's way of saying... Buzz off, I know it's broken and I don't want your bug reports anymore... I'd think those bug reports would be valuable to somebody who would eventually start working on it, so I don't know what the big deal is about "tired of seeing bug reports" about it. They don't know how to use bug filters over there? IMO, every bug report is valuable and they should be kept / accepted until somebody gets around to working on it..
                  So, you quote me but don't seem to realize that I'm the guy who disabled d3d1x. (I guess it would have been easier to know if my forum title said something about Intel.)

                  The point is that we shouldn't allow random users to try to compile known broken code. It doesn't do anything good. They may file bug reports about build breakages, but when it turns out that even with a successful build the code doesn't do anything useful then there's no point in fielding the bugs at all.

                  If you want to say that means "buzz off" I can't disagree. I don't want to see users waste their time building code that isn't used and is known to be broken.

                  Given your opinion, I presume that you don't realize that the last work to d3d1x was in October of 2011, and that the last work done on it by its original developer (who totally disappeared and doesn't respond to email) was in September 2010.

                  If you want to be the one to handle (and I mean fix) the d3d1x bug reports, be my guest. Until then, I'd personally appreciate the backseat driving to stop.

                  Comment


                  • #10
                    Originally posted by elanthis View Post
                    Yeah. Unfortunate, but not a surprise. I'd only seen a handful of commits to it over the last months. On the upside, a less politically charged modern graphics library to replace the crufty crap that is OpenGL actually is in the works.
                    yay

                    If you need an logo or something i can help.

                    Comment


                    • #11
                      Originally posted by mattst88 View Post
                      The point is that we shouldn't allow random users to try to compile known broken code. It doesn't do anything good. They may file bug reports about build breakages, but when it turns out that even with a successful build the code doesn't do anything useful then there's no point in fielding the bugs at all.
                      Are saying the DX10/11 demos they had running in d3dxl1 a year or two ago don't work anymore because d3d1x hasn't been updated along with the rest of mesa's internals?
                      It looked to me that, by default, the d3d1x wasn't compiled into mesa. And now, even if you specifically use the d3d1x build flag to compile it in, it won't?
                      It just seems a little early to be killing this off when Wine still hasn't got around to doing decent DX10/DX11 support and most open source graphics drivers are still struggling with OpenGL3.X..

                      Of course, it will still be a while before d3dxl1 is used as it is based on DX10/DX11 which depends on decent OpenGL3.X support.
                      Even if Wine doesn't want to touch d3d1x with a 10 foot pole, I'd think it would still be useful for demos/testing.... Or at the very least, couldn't it be used to make porting Direct3D Games to Linux *without* rewriting the whole engine to use OpenGL and *without* having to use Wine? I'd think that would be important for Linux gaming as it could significantly reduce porting costs.

                      The code might be a little stale, but it's still code for hardware that, for the most part, Gallium hasn't even gotten around to supporting well yet. It just seems to me that completely disabling it like that is pretty much a guarantee that it will very quickly fall into a state that it will be a lot of work just trying to get it to compile at all.

                      I don't mean to be a "backseat driver" but when I see stuff that could hurt the future of gaming on Linux, I always have to make a comment, that's all.

                      Comment


                      • #12
                        Originally posted by Sidicas View Post
                        It just seems a little early to be killing this off when Wine still hasn't got around to doing decent DX10/DX11 support and most open source graphics drivers are still struggling with OpenGL3.X..
                        While you didn't say so, I think it's worth pointing out that Wine devs stated multiple times that they have no interest in D3D support via G3D for multiple reasons. I guess they'd accept a well done, well separated code path that makes use of G3D, but it's not going to work that way with Wine's development model. Just look at how long it took for a working DIB engine to enter the Wine tree. Adding a G3D code path is a similar big and invasive task.


                        Originally posted by Sidicas View Post
                        Of course, it will still be a while before d3dxl1 is used as it is based on DX10/DX11 which depends on decent OpenGL3.X support.
                        Even if Wine doesn't want to touch d3d1x with a 10 foot pole, I'd think it would still be useful for demos/testing....
                        I can't imagine a single scenario where one would want to test anything with a broken D3D implementation which is more cumbersome to use than just setting up a Windows VM and using software rasterization (or a full windows dual-boot setup if that's too slow).

                        Originally posted by Sidicas View Post
                        Or at the very least, couldn't it be used to make porting Direct3D Games to Linux *without* rewriting the whole engine to use OpenGL and *without* having to use Wine? I'd think that would be important for Linux gaming as it could significantly reduce porting costs.
                        It could be used for that, but that would require someone to put some *very* substantial work into a) getting the D3D implementation in G3D to work close to perfectly (since you want a suitable replacement for Wine) b) getting it up to at least Wine's level of performance (no use in native D3D if it runs slower than Wine) c) getting the most popular drivers to actually work with the D3D implementation in G3D (that's not necessarily a trivial task).
                        Also, note that porting an application from Direct3D to OpenGL isn't necessarily hardest part of porting a whole application from Windows to Linux. So even if you had something like native D3D support in Linux, there'd be tons of other items to work on for the game developer.
                        Meanwhile, all the effort that would've gone into desperately making G3D support D3D properly could've just went into improving Wine.


                        Originally posted by Sidicas View Post
                        The code might be a little stale, but it's still code for hardware that, for the most part, Gallium hasn't even gotten around to supporting well yet. It just seems to me that completely disabling it like that is pretty much a guarantee that it will very quickly fall into a state that it will be a lot of work just trying to get it to compile at all.
                        I have no idea how often interfaces change in G3D, but you either end up with what you just explained or with the maintainers of G3D code wasting lots of time on code they don't really care about. It's enough work to maintain a single piece of software; if you have to bother about another one because the original maintainer randomly disappeared and doesn't show any interest in helping out anymore, there's really no excuse to leave that guy's piece of code any longer in the tree.

                        Originally posted by Sidicas View Post
                        I don't mean to be a "backseat driver" but when I see stuff that could hurt the future of gaming on Linux, I always have to make a comment, that's all.
                        Sorry, but even if someone removed the D3D code in G3D altogether, that wouldn't hurt the future of gaming on Linux at all.

                        Comment


                        • #13
                          Originally posted by Sidicas View Post
                          Even if Wine doesn't want to touch d3d1x with a 10 foot pole, I'd think it would still be useful for demos/testing.... Or at the very least, couldn't it be used to make porting Direct3D Games to Linux *without* rewriting the whole engine to use OpenGL and *without* having to use Wine? I'd think that would be important for Linux gaming as it could significantly reduce porting costs.
                          The problem is that Gallium3D isn't used everywhere. On the desktop, Intel (which *DO* have a significant market share, though) is the only using Gallium3D for their official driver, and AMD are also giving support to an opensource driver using it beside their official one. AMD and Nvidia official drivers aren't based on Gallium, but share code with their respective Windows equivalent. Currently for Nvidia (which is mega-popular among gamers) the binary driver is the preferred one as it is the only supported by Nvidia and nouveau is entirely done by reverse engineering (and thus is having a hard time to be on par, although it's quite amazing what they still managed to achieve anyway).

                          So, DirectX 3D on Gallium3D only solves the "Wine support & Game porting" problems for a fraction of the players. (The one with Intel hardware, and the few AMD/Nvidia interested in the opensource drivers). For the rest (the bulk of Nvidia and AMD running the official binary drivers) you need support from the company themselves - that might be made easy if they share code with the windows version, but on the other hand that still require extra work from them (and given how slow is Nvidia to pick up latest linux trends... Just look how much time it's taking them to pick-up RandR, to decide they might start playing with DMA-BUF to offer actual real optimus support instead of bumblebee workaround... Still don't even care to consider Wayland... Hence Linus' big "Fuck You". At least apparently the things are starting to move on the Tegra front and looks like Nvidia might go the AMD way).

                          For directx on Linux to make any sense, one would need:
                          - developpers jumping on to maintain d3d1x
                          - AMD and Nvidia porting their windows DirectX code to Linux

                          Better keep the current route:
                          - Developers are adding OpenGL support to their 3d engines anyway, in order to support Mac OS X and support OpenGL ES powered handheld devices (smartphone, tablets, etc.). As DirectX is only available on Windows and X-Box, and as OpenGL is available on pretty much everything *including* Windows and *including* all the juicy new emerging markets (mobile apps), it really does make sens.
                          - Bring OpenGL support on Linux on par with everything else. AMD and Nvidia are already doing their work on their binary drivers (with support of the recent OpenGL 4.x APIs). Gallium3D is lagging behind, but the pace at which it progress is accelerating, thank various developpers like Intel (they want to get an as good as possible opengl support) and Steam (they helped bring some of the OpenGL 4.x debugging APIs into Gallium3D because it helps them).

                          The only actual use case for a DirectX state tracker would be VMware :
                          They bought Tungsten graphics and have them work on their virtualized acceleration. If they move their guest drivers on Windows to using Galllium3D, a Direct3d state tracker will make sense.

                          Comment


                          • #14
                            Originally posted by mattst88 View Post
                            So, you quote me but don't seem to realize that I'm the guy who disabled d3d1x. (I guess it would have been easier to know if my forum title said something about Intel.)
                            Michael?

                            Comment


                            • #15
                              Intel drivers don't use Gallium

                              Originally posted by DrYak View Post
                              The problem is that Gallium3D isn't used everywhere. On the desktop, Intel (which *DO* have a significant market share, though) is the only using Gallium3D for their official driver, and AMD are also giving support to an opensource driver using it beside their official one.
                              RTFM!

                              Intel doesn't use Gallium(there were some porting to Gallium done over two years ago) for their drivers, only classic Mesa. Citing from Wikipedia:
                              Originally posted by Wikipedia
                              In November 2011, Intel 965g and Cell Gallium drivers were removed from the master branch of Mesa as unmaintained and broken.
                              And its not because Gallium isn't technically better, but because Intel Company put so much time and money into developing pre-gallium driver, that they aren't considering it would be worth of time/money, but especially regressions(they always happen), to switch to Gallium.

                              Comment

                              Working...
                              X