Announcement

Collapse
No announcement yet.

The State Of Gallium3D, Its Future, Etc

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

  • #11
    I think the first step will be guest API call -> state tracker on guest -> SVGA Gallium3D driver on guest -> virtual SVGA hardware -> OpenGL calls on host OS.

    That's what the current vmware SVGA docco implies (on sourceforge).

    Skipping the virtual SVGA and passing Gallium3D calls down from guest to host OS and running on a native Gallium3D driver seems like an interesting next step.

    Comment


    • #12
      Originally posted by bridgman View Post
      I think the first step will be guest API call -> state tracker on guest -> SVGA Gallium3D driver on guest -> virtual SVGA hardware -> OpenGL calls on host OS.

      That's what the current vmware SVGA docco implies (on sourceforge).

      Skipping the virtual SVGA and passing Gallium3D calls down from guest to host OS and running on a native Gallium3D driver seems like an interesting next step.
      How many of those are vmware specific? I mean, can KVM and Xen leverage on vmware's work?

      Comment


      • #13
        I believe the virtual SVGA hardware and its implementation on the host OS is specific to VMWare. The current effort is basically building a new and improved driver stack for *guest* OSes on top of VMWare's existing virtual hardware and *host* OS code, using Gallium3D to let a single hardware driver (SVGA) support a range of APIs and OSes.

        The real benefit to the open source community comes from getting the *rest* of the Gallium3D stack ready for everyday use, ie the benefit accrues to open source graphics users in general, not to competing virtualization solutions.
        Last edited by bridgman; 11-14-2009, 07:20 PM.

        Comment


        • #14
          Originally posted by Louise View Post
          How many of those are vmware specific? I mean, can KVM and Xen leverage on vmware's work?
          Why would a company (vmware) spend millions on some project (tg/gallium3d) and then allow/want/have their competitors leverage their work?

          Comment


          • #15
            Originally posted by bridgman View Post
            I believe the virtual SVGA hardware and its implementation on the host OS is specific to VMWare. The current effort is basically building a new and improved driver stack for *guest* OSes on top of VMWare's existing virtual hardware and *host* OS code, using Gallium3D to let a single hardware driver (SVGA) support a range of APIs and OSes.

            The real benefit to the open source community comes from getting the *rest* of the Gallium3D stack ready for everyday use, ie the benefit accrues to open source graphics users in general, not to competing virtualization solutions.
            Having a company behind with a business model is so nice for the regular user

            It will be interesting if this will have any impact on KVM and Xen. E.g. if they too have to focus on these things too, so they can offer competing virtualization solutions.

            I imagine that Citrix and Oracle could speed up the development significantly

            Novell is not really a player in virtualization. We use it a work, and it is really bad. It is as if they have a deal with MS to not focus on this area. That's how bad it feels for the enterprise user.

            So personally I think it is much more interesting what Red Hat lays out for KVM.

            I hope vmware will update http://www.x.org/wiki/GalliumStatus
            Last edited by Louise; 11-15-2009, 03:30 AM.

            Comment


            • #16
              One could say that VMWare is writing the state trackers across the top of the chart, and xorg developers are writing the drivers down the left hand side of the chart (although TG/VMWare is working on reference drivers like softpipe, plus SVGA).

              It's going to be interesting when the SVGA driver comes out and maybe we get a solid green line across the chart. I imagine softpipe will need an update at the same time, hopefully another solid green line. That should go a long way to building confidence in Gallium3D.

              Comment


              • #17
                What would be a reasonable timeframe for Linux end users in general? One year untill fully working Gallium3D with a ATI graphics card? When is this entire thing going to become ready for prime time?

                Comment


                • #18
                  Originally posted by bridgman View Post
                  One could say that VMWare is writing the state trackers across the top of the chart, and xorg developers are writing the drivers down the left hand side of the chart (although TG/VMWare is working on reference drivers like softpipe, plus SVGA).
                  Maybe the state tracker title should have colours as well?

                  If I read the chart correctly, if just one field have a DONE, then that means, that the state tracker is done as well...?

                  Originally posted by bridgman View Post
                  It's going to be interesting when the SVGA driver comes out and maybe we get a solid green line across the chart. I imagine softpipe will need an update at the same time, hopefully another solid green line. That should go a long way to building confidence in Gallium3D.
                  That would be so great! Maybe we should add "SVGA" as a state tracker, just to put a little pressure on them

                  What also is very interesting is what this will mean for AMD and vmware in terms of hardware recommendations.

                  Comment


                  • #19
                    My guess is that it will happen at different times depending on the GPU family -- focusing mostly on 3xx-5xx until that seems ready for prime time. Once the 3xx-5xx family is ready for general use, I expect the later generations will come along much more quickly.

                    The hard part is estimating how long 3xx-5xx will take, since until the VMWare SVGA announcement it was still looking like being the first Gallium3D driver to reach general usefulness -- although you could argue that the nouveau driver is already there since there *is* no classic mesa driver to replace.

                    Developer focus has only shifted to Gallium3D in the last few weeks, although Corbin and others have been bravely pushing it ahead for most of the last year. There's also some effort happening on both 3xx-5xx and 6xx+ (some of it offline) working out flow control and other bits to enable GLSL support, which will probably show up in both classic and Gallium3D drivers.

                    If you look at the commit history for gallium3d drivers and classic mesa drivers the commit activity in the two subtrees is about the same these days, which is great to see :

                    classic mesa DRI drivers : http://cgit.freedesktop.org/mesa/mes...sa/drivers/dri

                    gallium3D drivers : http://cgit.freedesktop.org/mesa/mes...allium/drivers

                    I'm not close enough to the work to offer a real good estimate, but my guess is closer to 6 months than a year. If the VMWare efforts result in a ready-to-use stack (on a VMWare guest VM) soon that's an indication the framework is ready and the timeline for ATI graphics would probably be shorter as well.

                    The official schedule is still "it'll be done when it's done", of course.

                    Originally posted by Louise View Post
                    That would be so great! Maybe we should add "SVGA" as a state tracker, just to put a little pressure on them
                    I did not get the impression that additional pressure on the developers was required. They sounded pretty tired already
                    Last edited by bridgman; 11-15-2009, 12:17 PM.

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      [snip]
                      The official schedule is still "it'll be done when it's done", of course.
                      Everything just got a lot more exciting

                      Originally posted by bridgman View Post
                      I did not get the impression that additional pressure on the developers was required. They sounded pretty tired already
                      Good observation

                      Comment

                      Working...
                      X