Announcement

Collapse
No announcement yet.

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

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

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


            • #16
              Originally posted by Luke_Wolf View Post
              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.
              VMWare had nothing to do with this. It was a 1 man project by a nouveau driver community developer.

              Comment


              • #17
                Good riddance! There is absolutely NO excuse for implementing ballmer SHIT in Linux. Keep the SHIT away.

                Comment


                • #18
                  Originally posted by droidhacker View Post
                  Good riddance! There is absolutely NO excuse for implementing ballmer SHIT in Linux. Keep the SHIT away.
                  Steve Ballmer is not a programmer and have absolutely nothing to do with Direct3D.

                  Why is Direct3D shit?
                  Have you ever used Direct3D?

                  Maybe it is a very well-designed coherent API?

                  Comment


                  • #19
                    Originally posted by uid313 View Post
                    Steve Ballmer is not a programmer and have absolutely nothing to do with Direct3D.

                    Why is Direct3D shit?
                    Have you ever used Direct3D?

                    Maybe it is a very well-designed coherent API?
                    You replied to a troll and Linux fanatic - next time just ignore such utterances.

                    Comment


                    • #20
                      Originally posted by smitty3268 View Post
                      VMWare had nothing to do with this. It was a 1 man project by a nouveau driver community developer.
                      I guess that's what I get for trusting phoronix to report accurately
                      For those thinking that Direct3D 10/11 on Linux will be sub-par, "Finally, a mature Direct3D 10/11 implementation is intrinsically going to be faster and more reliable than an OpenGL implementation, thanks to the dramatically smaller API and the segregation of all nontrivial work to object creation that the application must perform ahead of time."

                      VMware previously was working on a Direct3D state tracker and it was not going to be open-source and primarily targeted for Gallium3D on Windows, but this is different and is open-source thanks to its development by a community members. This VMware / Tungsten state tracker also targeted Direct3D 9.0.
                      (emphasis mine)
                      from http://www.phoronix.com/scan.php?pag...3d_d3d11&num=1

                      led me to believe otherwise

                      Comment

                      Working...
                      X