Announcement

Collapse
No announcement yet.

The Linux Graphics Documentation That's Needed

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

  • The Linux Graphics Documentation That's Needed

    Phoronix: The Linux GPU Documentation That's Needed

    A week ago we shared that the first of the slides and videos from VMware's recent Gallium3D workshop were now posted on the Internet. This morning some more of this content is being published, which covers the VMware SVGA driver status, a Gallium3D state tracker overview, and the status of the OpenGL ES state tracker...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Tell us what you need, and we'll leak it.

    Works for me

    Comment


    • #3
      Video summery: OpenCL, soon. D3D, not soon.

      I imagine having Direct 3D on Linux would make WINE developers very happy

      I wonder, if they are in favour of that, and maybe supporting it...

      Comment


      • #4
        Some ideas

        I signed up just to respond to this because it's probably the biggest obstacle I've run up against when trying to get involved with X testing and development.

        One thing that would be helpful is perhaps some good pointers on books that could teach me how graphics cards and X work. C has the "K&R C" book. The Linux kernel has "Linux Device Drivers" and probably more. Is there something analogous to these fundamental books in the open source graphics drivers world?

        Another thing which might have less to do with documentation and more about packaging. It would be nice if there was an easy way to build an entire X stack, without all of the dependency hell. Perhaps distributions could add a metapackage that pulls in all of the development packages needed. If something like this already exists, then it sure would be nice to know.

        Another thing is the freedesktop.org and x.org websites. I'm never sure which I need to go to when looking for information about the various layers of the graphics stack. I'm not trying to be nit-picky. I'd really like to help with the graphics stack, but some of these barriers make it pretty tough to get started.

        Comment


        • #5
          Originally posted by Louise View Post
          I imagine having Direct 3D on Linux would make WINE developers very happy
          No, it won't. That's a common myth, but it's false. It would make them happy if it allowed them to ditch their D3D->openGL wrapper, but it doesn't.

          First of all, Wine is supposed to run on linux, macos, *bsd and solaris. If only one of these platforms starts supporting D3D natively, they haven't gained anything at all. I can imagine *bsd getting support (eventually), but D3D on macOS just isn't going to happen.

          Second, the wrapper is being used outside of wine, for example for Virtualbox's accelerated rendering - only openGL can be accelerated on the client, as such D3D has to be translated first.

          Hence the wrapper will continue to be needed for quite some time, both inside and out of wine, and a native D3D interface doesn't help at all.


          There is one group that may be interested in a native D3D interface, and that's companies attempting to port games to linux. But as D3D is closely connected to other windows-specific APIs, I'm not sure how much work it really saves compared to just rewriting the rendering pipeline in OGL.

          Comment


          • #6
            Besides, why would we want to be strapped in to a reverse-engineered implementation of a Micro$oft-controlled system? Using OpenGL (for all 3D applications on all platforms) would be the easiest thing for everyone.

            Comment


            • #7
              Originally posted by rohcQaH View Post
              Second, the wrapper is being used outside of wine, for example for Virtualbox's accelerated rendering - only openGL can be accelerated on the client, as such D3D has to be translated first.

              Hence the wrapper will continue to be needed for quite some time, both inside and out of wine, and a native D3D interface doesn't help at all.
              Okay, that was some quite good arguments, that I hadn't really thought of.

              Sadly we can 100% sure that Oracle will stop development of VirtualBox, once they acquire Sun. Oracle already have 4 or 5 virtual machines. Most of them are Xen based, like their own Oracle VM.

              It wasn't too long ago, they bought a small, but very promising Xen virtual machine company, and killed it afterwards.

              Getting VirtualBox is just perfect for Oracle. One less competitor to worry about.

              It is a trade off with Oracle. They are VERY pro Linux and open source, in the areas, where it benefits them, and for rest rest, they rip, slice, shred, and kill the rest, in a way that makes even Balmer say, "That's enough."

              Comment


              • #8
                Originally posted by thefirstm View Post
                Besides, why would we want to be strapped in to a reverse-engineered implementation of a Micro$oft-controlled system? Using OpenGL (for all 3D applications on all platforms) would be the easiest thing for everyone.
                No idea. But VMware is working on it, so some sort of business model or customers do they have.

                So apparently there exist a program that requires D3D, and they want on Linux.

                maybe it is a developer debug tool?

                Comment


                • #9
                  I thought they were talking about D3D for Windows guest OS, not for Linux. Did I miss a juicy comment somewhere ?
                  Test signature

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    I thought they were talking about D3D for Windows guest OS, not for Linux. Did I miss a juicy comment somewhere ?
                    Okay, that would be awesome, if that was what they are working on I just assumed if was the other way around.

                    Won't that require VMware to write their own D3D driver for Windows?

                    Comment

                    Working...
                    X