Announcement

Collapse
No announcement yet.

Direct3D In Gallium3D Suffers Bit-Rot, Now Disabled

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

  • #16
    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. 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.

    To bad that WINE and YOU are wrong!!! The D3D(or HLSL) state-tracker, doesn't need heavy translations, and doesn't need D3D dlls. Its easier to maintain than the current alpha-state WINE D3D-compiler, and does not need support from Nvidia nor AMD. It will only need a back-end in order to work with closed drivers. You can use LLVM, but some one need to continue development. As for patents, come one now. Microsoft said that Linux-Kernel and WINE violate their patents.

    Comment


    • #17
      d3d1x

      It simply isn't quite finished and still has a number of bugs.
      It was *always* usable with WINE, and you could run Unigine Heaven (the Windows version, via WINE) with it (with a hack to bypass TGSI and hand SM4 to the driver, which is only handled by the Fermi driver).
      But not any actual game. Unimplemented features, bugs -> crash.
      And no one cares about it anymore. It could have been a great success for gallium if more people (developers) ever had ...

      Comment


      • #18
        D3D in Gallium was a good idea, IMO. Personally, I find it to be a nicer API to work with than OpenGL (where for me nicer==easier.) But if nobody's using it (or even maintaining it), then there's no point.

        Though it might be a bit of a chicken & egg problem - nobody is maintaining it because no one's using it, and no one's using it because it's not maintained and therefore its future looks grim.

        (I've got no idea or opinion about the legal stuff.)

        Comment


        • #19
          Originally posted by evil_core View Post
          RTFM!

          Intel doesn't use Gallium(there were some porting to Gallium done over two years ago) for their drivers, only classic Mesa.
          The point still stands. The point was "D3D via Gallium3D would be useful only for a small fraction of users", and you just prove it's a smaller fraction than he thought it was.

          Originally posted by artivision View Post
          To bad that WINE and YOU are wrong!!! The D3D(or HLSL) state-tracker, doesn't need heavy translations, and doesn't need D3D dlls. Its easier to maintain than the current alpha-state WINE D3D-compiler, and does not need support from Nvidia nor AMD. It will only need a back-end in order to work with closed drivers. You can use LLVM, but some one need to continue development. As for patents, come one now. Microsoft said that Linux-Kernel and WINE violate their patents.
          I think he means the support from closed source drivers is needed to get a dev to actually want to use D3D on Linux. And I think he is right, most gamers use closed source drivers (and the apps are usually made with a kind of user in mind, which, for D3D apps, is likely a gamer), and what you suggest is to, essentially, code in D3D and then translate to OpenGL for the blobs. That would mean a useless performance loss for blobs, which are benefitted by direct OpenGL use. The other option, coding for both OpenGL and D3D, which would make everyone happy, except for the dev, who would have to write and maintain duplicated code. But then, you could just do it OpenGL, which support is WAY more universal, specially on FLOSS OS's, where blobs supports it and FLOSS drivers supports it (at least, at a better extent than D3D), and, most important, the (almost) OS independent drivers (classic mesa) supports only that.
          Personally, I use the open source drivers, and I'd love to see more features added, and better performance, and what not. But I don't really see the point in keeping coding apps for both API's, coding once is easier than coding twice, and dropping OpenGL means dropping several platforms (I think of the *BSD and Haiku guys, for example) and drivers, while dropping D3D means just dropping D3D (well, I don't really mean dropping, because I'm talking about software that it's not there yet ). So, the main use would be for already existing software, being via WINE or via porting it. And again, most of it already uses OpenGL, which means you could just port it to use OpenGL on the new OS or just use it with OpenGL on WINE.

          Comment


          • #20
            Originally posted by Sidicas View Post
            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..
            The D3D demos aren't useful for users.

            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 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.
            It's already in a state where it's a lot of work to get it to compile...

            Comment


            • #21
              GOOD RIDDANCE.
              One more blob of balmer's jizz we don't need or want polluting our sand box.

              Comment


              • #22
                Hmm, I already wondered why mesa compilation failed on some architectures when d3d was enabled. Had hoped for some possible compatibility or performance enhancement for wine, but oh, well.

                Comment

                Working...
                X