Announcement

Collapse
No announcement yet.

The Most Important Project Since Mesa 1.0?

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

  • #51
    Forgive me if this has already been asked, since I only had time to skim the thread, but doesn't this mean support could be passed through to programs like Virtualbox or QEMU to get better performance than Wine's d3d? Last time I checked, Wine's lib is how Direct3D works in Virtualbox at the moment, although they have an experimental WDDM driver architecture working.

    Even still, I do like the idea of Gallium3D taking advantage of its portable nature someday and supporting a much wider base of operating systems.

    Comment


    • #52
      Originally posted by Luke_Wolf View Post
      got a link to that letter to the court? This is the first I've heard of it.

      Comment


      • #53
        Originally posted by scionicspectre View Post
        Forgive me if this has already been asked, since I only had time to skim the thread, but doesn't this mean support could be passed through to programs like Virtualbox or QEMU to get better performance than Wine's d3d? Last time I checked, Wine's lib is how Direct3D works in Virtualbox at the moment, although they have an experimental WDDM driver architecture working.

        Even still, I do like the idea of Gallium3D taking advantage of its portable nature someday and supporting a much wider base of operating systems.
        I don't know how their stuff works, but I think what they want is a WDDM DDI driver with a fake GPU underneath. The way this is implemented would replace the D3D stack (d3d9.dll) which is arguably not very virtualization friendly. I suppose though, if they just want a full pass-through, they could totally do that. It wouldn't work on proprietary drivers unless someone writes pipe_gl or they keep wined3d as a backup (like we do), but it's perfectly possible.

        If someone wants to, the Windows DDI for GPU drivers could be implemented and it would be a small matter of some kernel integration to get it running with the official D3D stack. However, I just don't give a damn about Windows. If someone wants to, go ahead, but it would require a near full rewrite of nine.

        Comment


        • #54
          The way I see it is that older software would work better as most new games use DirectX 10/11 and/or OpenGL anyway. DirectX 9 is dying at best, so it shouldn't pose any threat to future DirectX vs OpenGL smack talk.

          Comment


          • #55
            Considering there are new games being developed for Direct3D 9 such as StarCraft 2: Legacy Of The Void. and the lifespan of such a game is at least 5 years, I don't expect Direct3D 9 to become irrelevant until 2018.

            It's not important how many games support Direct3D 10/11. The only thing that matters is how many games supporting Direct3D 10/11 do not support Direct3D 9. And that number should be pretty big for us to even care about Direct3D 10/11.

            The likely scenario is that Mesa will eventually support acceleration of all popular Direct3D APIs.

            Comment


            • #56
              So, how can I install the Direct3D 9 state tracker?

              and I would like to see benchmarks of this patch enabled against the default wine.

              Comment


              • #57
                Regardless of anything else, the #1 reason no major vendor is going to use an open source driver on Windows is that doing so will mean computers with their GPUs will be blocked from being able to play back protected content by Microsoft.

                Comment


                • #58
                  Originally posted by jonwil View Post
                  Regardless of anything else, the #1 reason no major vendor is going to use an open source driver on Windows is that doing so will mean computers with their GPUs will be blocked from being able to play back protected content by Microsoft.
                  There's a number of reasons why an open source driver would never work in Window. What you're referring to is Silverlight with Netflix. Even then, eventually Netflix will switch over to HTML5.

                  Comment


                  • #59
                    Originally posted by Dukenukemx View Post
                    There's a number of reasons why an open source driver would never work in Window. What you're referring to is Silverlight with Netflix. Even then, eventually Netflix will switch over to HTML5.
                    No, I am talking about ALL content that uses the "Protected Media Path" functionality in Windows. (where the player that is trying to play the content will refuse to play unless all the components in the playback chain have been signed and verified by Microsoft)

                    Comment

                    Working...
                    X