Announcement

Collapse
No announcement yet.

DirectX 10/11 Coming Atop Gallium3D

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

  • #16
    I just have to laugh at the responses here. Who do you think you people are? Seriously. Your community (as in "Linux community", whatever that is to you, to me it's the money behind Novell and Red Hat coupled with a few lunatics) is irrelevant. When are you going to grasp that? "Allowing developers to be lazy." Pretty neat, that one. The less compatible Linux is to Windows, the less people are going to use it.

    Some people simply don't understand reality. The developers of DX application *don't give a damn* about all your perfectly valid points because *you don't matter*. You can discuss all their wrong doing the whole day. You still don't matter.

    You want to matter? Be compatible to Windows.

    Comment


    • #17
      Originally posted by RealNC View Post
      [blah blah blah]

      You want to matter? Be compatible to Windows.
      You want to matter? Be compatible to Windows thank to OpenGL.

      Hehehehe

      Comment


      • #18
        OpenGL drivers are so buggy it's not even funny anymore. Yes, that includes nvidia, too.

        Comment


        • #19
          Meh, at least we could play Microsoft and Embrace & Extinguish DX.
          We release DX12 that is improved in in every way compared to 11, while binding it to linux-only functionality for maximum advantage.

          ...Or not...

          Comment


          • #20
            Originally posted by droidhacker View Post
            The only thing that it does is it gives MS more control over Linux by allowing developers to be LAZY.

            1) This doesn't help -- the developer can make a more intelligent choice in APIs to start their project, resulting in less duplicated work.
            2) Waste resources in bad areas that could be used in more universally useful areas, like GPU-independent video decode acceleration.
            3) There would be more pressure on OpenGL to be better if more people were actually interested in it, this goes back to #1.
            4) Interesting, but when has MS ever relinquished control over anything in favor of open source? In fact, as a counter argument, MS has a tendency to break things that they DO NOT control in THEIR implementation in order to STEAL control.... i.e. their creative interpretation of HTML in their dysfunctional web browser. Because MS renders it WRONGLY, some developers conform to that broken renderer, resulting in web pages that render correctly only when incorrectly rendered by MS.
            I like your passion, but there are many perspectives at play here...

            1. How would you account for existing code that can be ported to Linux, and/or re-used into new products. It's expensive to throw out and start new. And regardless, there are also those who feel that the D3D API meets their needs better than OpenGL and as such would be the 'intelligent' choice.

            2. The company implementing D3D is doing so to meet their needs, so they don't feel it's a waste of resources. When implementing such features, the universal problems that need to get solved might get addressed. And with D3D in place, it might attract *new* developers/companies to use Gallium3D and Linux in general who will improve/enhance it to meet their needs (which may or may not include the issues you care about). So I'm not looking at allocation of existing resources, I'm asking if this will draw new resources (who may or may not care about your 'universal' issues)

            3. If OpenGL was the "intelligent choice" then more people would use it (Saying it's so doesn't make it so...) OpenGL has to stand on it's own, not because there are no other choices. Things either evolve to meet new competition or they die (including Linux), wanting to be relevant doesn't mean anything (except perhaps in driving flame wars and result-less conversations on blogs)

            4. As long as the API is documented and consistent, then I don't really care who controls it (perhaps you do, but I'd rather a complete solution than a half baked home grown solution). The issue with HTML was MS's tendency to diverge from the standard. It doesn't serve MS to radically keep re-inventing their API, and they are not going to change a D3D api that is already in place. As long as they document it then why not leverage it. Then we can invest our limited resources in areas of innovation that matter.

            I'm not really here to argue right and wrong... I'm just pointing out that arguments of good vs bad miss out on stepping back and considering other possibilities. I'm simply asking what good can come of this.

            At the end of the day, developers are lazy... in fact it's a good mantra for life - there is not enough time or money to do everything, so let's re-use and leverage whatever we can to get the job done.

            This leaves us money/time/energy to focus on truly important things like true innovation (or at least fixing gaping holes). If D3D on Linux is this time saver, then it will thrive, otherwise it will die.

            And I agree with RealNC... peoples opinions don't matter. What matters here is the need and someone clearly feels there is a need for D3D on Gallium3D which may or may not be ported to Linux. I'm just suggesting that this need might build momentum for others to come join the playground who have different views than yours (or mine)... and I believe that is a good thing.

            Comment


            • #21
              Originally posted by curaga View Post
              Meh, at least we could play Microsoft and Embrace & Extinguish DX.
              We release DX12 that is improved in in every way compared to 11, while binding it to linux-only functionality for maximum advantage.

              ...Or not...
              Now, that thought brings a smile to my lips.

              And there's a perfectly suitable extension to D3D for this approach: quad buffer stereo. Maybe framelock extensions, too - there are developers who would positively kill to have those features in D3D. It is actually rumoured that QBS will be the next "big" feature for D3D12, but (a) that's a couple of years away and (b) there's a whole new market emerging here (new 120Hz HDTVs, 3d Bluray etc).

              The window of opportunity is here, any takers?

              (I'm only half-joking. Wouldn't it be awesome to beat Microsoft in their own game?)

              Comment


              • #22
                Originally posted by RealNC View Post
                I just have to laugh at the responses here. Who do you think you people are? Seriously. Your community (as in "Linux community", whatever that is to you, to me it's the money behind Novell and Red Hat coupled with a few lunatics) is irrelevant. When are you going to grasp that?
                Who is this guy? I've never heard of him, so none of his post matters to me.

                Really, though, only the rich deserve to express their opinions.

                Comment


                • #23
                  Originally posted by BlackStar View Post
                  quad buffer stereo.
                  Ha - the first thing that came to mind was you mean 4 layers of buffering for Stereo sound on Linux... that would be a unique Linux feature that explains the lag in Skype with PulseAudio :-)

                  Comment


                  • #24
                    Originally posted by droidhacker View Post
                    2) Waste resources in bad areas that could be used in more universally useful areas, like GPU-independent video decode acceleration.
                    DXVA2 on linux.... that's one hell of an idea!

                    Comment


                    • #25
                      Originally posted by BlackStar View Post
                      OpenGL drivers are so buggy it's not even funny anymore. Yes, that includes nvidia, too.
                      I'm pretty sure driver developers are perfectly able to load the Direct3D state trackers with bugs too.

                      Comment


                      • #26
                        Originally posted by Remco View Post
                        I'm pretty sure driver developers are perfectly able to load the Direct3D state trackers with bugs too.
                        Current D3D drivers are easily an order of magnitude more stable than OpenGL, not the least because they use a common HLSL compiler instead of 5 different ones.

                        In fact, today I was debugging a GLSL shader that's interpreted differently by all three major vendors. With a tiny tweak, I can cause an access violation on Ati, a black screen on Nvidia and multicolored sparkly rendering on Intel (with current drivers). Three mutually incompatible interpretations of the same code - beat that!

                        I dread to think what will happen if I add Mesa and OS X drivers into the mix...

                        Comment


                        • #27
                          Originally posted by BlackStar View Post
                          Current D3D drivers are easily an order of magnitude more stable than OpenGL, not the least because they use a common HLSL compiler instead of 5 different ones.

                          In fact, today I was debugging a GLSL shader that's interpreted differently by all three major vendors. With a tiny tweak, I can cause an access violation on Ati, a black screen on Nvidia and multicolored sparkly rendering on Intel (with current drivers). Three mutually incompatible interpretations of the same code - beat that!

                          I dread to think what will happen if I add Mesa and OS X drivers into the mix...
                          The nice thing about Mesa is that it will be used for all open source drivers. If it renders a particular shader instruction as a multicolored sparkly screen, at least it will do so across the board.

                          Comment


                          • #28
                            no source for DX state trackers

                            VMware won't be releasing any source for DX* state trackers.

                            Zack was talking about the Gallium core getting support for DX10/11 *features* so they could build a DX10/11 state track on top of them.

                            Comment


                            • #29
                              This is silly. New applications should use OpenGL, and Wine can use the DX interoperability features of OpenGL 3.2 (vertex_array_bgra, provoking_vertex, etc.). This is just wasted effort that would be better spent on OpenGL 3 support.

                              Comment


                              • #30
                                Originally posted by md1032 View Post
                                This is silly. New applications should use OpenGL, and Wine can use the DX interoperability features of OpenGL 3.2 (vertex_array_bgra, provoking_vertex, etc.). This is just wasted effort that would be better spent on OpenGL 3 support.
                                Only if you no clue about what GL3 and 3.2 are. They are mainly GL implementations of DX10/11 bits.

                                And since VMware need to write DX10/11 state tracker anyway for their OS drivers I guess its not a wasted effort for them.

                                Dave.

                                Comment

                                Working...
                                X