Announcement

Collapse
No announcement yet.

Gallium3D's Direct3D 10/11 State Tracker To Be Nuked

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

  • Gallium3D's Direct3D 10/11 State Tracker To Be Nuked

    Phoronix: Gallium3D's Direct3D 10/11 State Tracker To Be Nuked

    The Direct3D state tracker for Gallium3D that for a short time provided hope of a native Direct3D implementation for Linux of the Microsoft Direct3D 10/11 APIs without simply being a translator layer to OpenGL, is set to be nuked from mainline Mesa...

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

  • #2
    That's beyond sad - a code which allowed to run Direct3D code natively has been purged.

    Damn.

    And Wine doesn't quite support Direct3D 10 yet.

    Damn.

    Comment


    • #3
      I'm guessing Gallium-based D3D1X can't be used on intel graphics, and you know why wine developers don't want it.

      Comment


      • #4
        I agree, this is sad... so why not do something about it? Phoronix could organize an Indiegogo campaign to fund development for a few months. I'd be surprised if nobody with the required knowledge was willing to dedicate some time to this if they could be paid.

        Comment


        • #5
          Originally posted by tadpole View Post
          I agree, this is sad... so why not do something about it? Phoronix could organize an Indiegogo campaign to fund development for a few months. I'd be surprised if nobody with the required knowledge was willing to dedicate some time to this if they could be paid.
          The problem isn't a few months, it's ongoing maintenance over the long run.

          Whenever someone changes the gallium interface, build system, or other misc. large changes, they have to go in and fix up this state tracker, and no one really knows much about it or tests to make sure they aren't breaking it. And since no one is really using it, removing the code makes sense. If someone had the time to maintain it in the long term, it would stay. Paying someone to do that for a few months won't fix anything though.

          Comment


          • #6
            I's indeed VERY sad that project ends this way...

            ...and indeed, WINE is far far away to even support Dx10....only a very limited set of functions are supported (IIRC) and in practice, it can't run any Dx10 game, not to mention Dx11.

            Comment


            • #7
              The reason it has died is because Wine developers didn't wanted it. IMHO it should have been the way Direct3D support should have been implanted from the start (it's a graphic API as OpenGL, as such it belongs there). Afterward the rest of DirectX API could have been implanted aside and enabled developers to compile DirectX game with less porting effort. I don't quite know why such a project didn't picked up more steam. It is some kind of OpenGL protectionism? Or maybe Wine developers think this would have split Windows-emulation effort on Linux and didn't see this as a good thing? I don't know. There is hostility against implementing Microsoft technologies on Linux. Quite sad I think. Anything that can bring more native game to Linux is good.

              Comment


              • #8
                Could have been useful for people with Direct3D experience, coming to Linux and wants to keep on play with it.
                Or people who use Linux but wants to learn Direct3D, or people who maybe works with Direct3D as their job, but personally prefer to use Linux.

                Would have been pretty cool to have a Direct3D implementation even if its just Direct3D and not DirectX.

                Comment


                • #9
                  I see this as nothing lost. The last thing we need is for all new games that come to Linux is for them to be wrapped in Wine to make them half functional.

                  Games need to be ported native or not at all. Don't believe me? Go ask the Mac users how "great" Cider(based on Cedega) has been for Mac gaming.

                  Comment


                  • #10
                    The only problem that I've been having with wine using the oss radeon driver has been that directx games have been too slow to be playable. Besides that everything seems really good with wine. I think if it was able to natively render directx this performance probl;em wouldnt exist. Think of it like this, if the oss driver stack doesnt have the functionality to properly support a native directx renderer, how much worse is it to tranlate into opengl and then render? If the stack doesnt have the capability of properly supporting directx, then what kind of hackish crap must wines translation be doing to make an opengl representation?

                    For those directx capabilities that are unsupported by the stack, how are they translated into opengl? Unsupported capability is unsupported capability...

                    The solution here is not this hackish crap that wine is trying to do... The solution is to add the capability to the stack that is required for a native directx implementation to function properly.

                    Comment


                    • #11
                      Originally posted by Kivada View Post
                      I see this as nothing lost. The last thing we need is for all new games that come to Linux is for them to be wrapped in Wine to make them half functional.

                      Games need to be ported native or not at all. Don't believe me? Go ask the Mac users how "great" Cider(based on Cedega) has been for Mac gaming.
                      This could have been used for native apps. I'd much rather work with a sane, modern API like D3D11 than the 1980's-style mess of OpenGL. Doing the other portability work is still a big sink of time/money, but it's a hell of a lot better than trying to deal with GL in an app designed for D3D11. It's like porting an app from Qt to GTK+: they both work, but using the original is just way faster and easier to do the same things. I still say someone other than Khronos needs to do a NotStupidGL so the anti-Microsoft zealots won't freak out about seeing DirectAnything but people who want to get work done have a better API than OpenGL; I've heard rumblings of a few projects like this (and debated doing my own on Gallium) but nothing yet. I won't claim it would be easy; it won't. But it'd be a fun project that would do the world a lot of good. Google is likely to jump on it since OpenGL bindings in Java are... awful. GL wasn't designed for bindings or wrapping at all, compared to D3D which is pretty easy to bind or wrap.

                      A big sticking point for a pure D3D reimplementation is that the binary shader format for newer HLSL shader models is no longer documented, _and_ the d3dcompiler_xx.dll is no longer part of the "public" API. I took a DX developer to task over this at the bar last Wednesday; their excuses boil down to (a) they don't want to have to maintain compatibility, which is stupid (and I told them so), they have to maintain compatibility _anyhow_, and can continue to do so with binary DLLs on Windows, and (b) their division is massively understaffed for how critical DX is to all of Windows now and they don't have spare cycles to maintain any more documentation. As is no surprise here, interoperability is not at all the highest item on their list of priorities, or even on their list of priorities right now. Unfortunately, drunkenly berating core developers in a bar has no effect on managerial prioritization. The shader compiler thing isn't just for GL compatibility, though; it bars a lot of useful and cool kinds of apps from the app store because they can only use precompiled shaders. Shader development apps, toys, or user-modifiable graphcs pipelines are impossible on the app store without the ability to programmatically generate shaders. It's like banning all scripting languages, except for the GPU.

                      I also pointed out that if Win8 wants to make any inroads into tablets and phones, it's now in the unfortunate position where it has to acomomadate Khronos' crap. Which doesn't mean adding OpenGL|ES support necessarily, but making it easier to write complete wrappers would help. That means making the HLSL compiler part of the full API (it's barred on Win8 store apps as an internal-only feature) or documenting the binary interface, as well as adding configuration calls to make the few places where D3D and GL are incompatible (screen coordinates, depth buffer ranges, etc.) be able to be set to a GL-compatible mode. (It's completely stupid that Khronos, with the extensible GL, hasn't done the reverse already, especially since in a few cases the D3D approaches are quantitatively more correct, but MS either needs to play ball if they want to make it easy for devs to port their existing apps over quickly.) Maybe that argument will get up to a high-ranking PM and they'll act on it. Probably not, but here's hoping.

                      Comment


                      • #12
                        Originally posted by werfu View Post
                        I don't quite know why such a project didn't picked up more steam. It is some kind of OpenGL protectionism? Or maybe Wine developers think this would have split Windows-emulation effort on Linux and didn't see this as a good thing? I don't know.
                        It's pretty simple really. This would have been only good for Mesa Gallium drivers. Maybe, if it took off, maybe, it could eventually get ported onto Intel. But the chances of ever getting it onto the proprietary drivers had to be considered almost non-existant.

                        And then, what is the point? You'd end up with apps that had to do double the work - one codebase to run on the proprietary drivers in OpenGL, and another seperate one to run on the Mesa drivers in D3D. No one wanted to do that.

                        This could have been a good experiment, something for people to play around with. But i think in the end, it didn't even get that much attention because it was always a work in progress.

                        Comment


                        • #13
                          Thats kind of a retarded argument tho... We didnt want to implement much needed functionality that the proprietary drivers didnt already have.... Sounds really dumb...

                          I think it is more likely that supporting it would simply have been difficult and there wasnt enough man power to support it.

                          Comment


                          • #14
                            Originally posted by duby229 View Post
                            Thats kind of a retarded argument tho... We didnt want to implement much needed functionality that the proprietary drivers didnt already have.... Sounds really dumb...

                            I think it is more likely that supporting it would simply have been difficult and there wasnt enough man power to support it.
                            How is it retarded to not implement something no one would ever use?

                            Yes, obviously the reason was a lack of manpower. The point is that the lack of manpower existed because no one would have used it. Hence, no interest in providing manpower.

                            Comment


                            • #15
                              Well, I must say I'm actually kinda surprised that VMWare didn't continue developing it after that initial push. I mean my understanding at the time from the articles was that they were developing it in order to get direct3d 10/11 client support. Yes the community didn't exactly accept it or decide to get behind it but I'd have thought their corporate interest if nothing else would have driven it forward. Oh well, maybe in the future we'll see some game developers working on this if the virtualization people aren't going to.

                              Comment

                              Working...
                              X