Announcement

Collapse
No announcement yet.

VMware Releases Its New Gallium3D Driver

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

  • #16
    Originally posted by bridgman View Post
    Louise, I think SVGA just refers to the emulated "Super VGA" (ie an enhanced VGA chip) that VMWare has been providing for some years to provide graphics on guest OSes. The emulated SVGA chip received hardware acceleration extensions recently but driver support was relatively weak until now.

    There's info available at : http://sourceforge.net/projects/vmware-svga/
    Thanks for clearing that out

    Comment


    • #17
      Originally posted by bridgman View Post
      Craig73 - AFAIK the emulated SVGA uses OpenGL calls on the host OS to execute commands sent from the guest driver stack. It probably does make sense to replace this with Gallium3D calls on the host OS in the future but that would be an optimization and isn't necessary to make things run today. That's what the docco says anyways.
      Hmmm... that would make sense for what is in place today... perhaps I need to follow the links and read a bit more (lot's of layers here :-) )

      I imagine (without further reading) - someone running an OpenGL app would run the OpenGL state tracker, which would translate calls into Gallium3D TGSI, perhaps optimizing it, which would translate it the 'virtual SVGA' hardware... which is a generic OpenGL command set to pass to the host OS? (Which then would be optimized in Mesa, and then translated into hardware instructions by the XOrg/Mesa driver).

      And all other state trackers would translate into OpenGL calls

      I guess it's progress regardless... because some level of acceleration is available, which usually makes up for the extra layers :-)

      Comment


      • #18
        Given that qemu already has some (older) support for the vmware svga driver, there's nothing (in theory) preventing it from supporting this driver... right?

        Comment


        • #19
          Hi, I'm one of the VMware 3D developers. I didn't work directly on the Gallium driver but I do work on the 3D backends and had a substantial contribution to the WDDM driver that we shipped with Workstation 7.0.

          Yeah, SVGA just means "Super VGA", it was an extension of the VGA device that we initially shipped and the people responsible for naming things at that point were less creative with the names

          Originally posted by Craig73 View Post
          I imagine (without further reading) - someone running an OpenGL app would run the OpenGL state tracker, which would translate calls into Gallium3D TGSI, perhaps optimizing it, which would translate it the 'virtual SVGA' hardware... which is a generic OpenGL command set to pass to the host OS? (Which then would be optimized in Mesa, and then translated into hardware instructions by the XOrg/Mesa driver).
          Close, TGSI is only used as a shader language temporarily in the driver; it's intended to be an intermediate representation that gets translated by the gallium hardware-specific code into whatever the hardware needs. The state tracker manages a lot of other state as well but most of the traditionally fixed function aspects of OpenGL (fogging, lighting, most of the transform and projection state) are converted to shaders and shader arguments. There are a lot of things that aren't directly shader state like texture bindings and blend modes which are still handled separately from the shader code.

          The VMware Gallium driver translates the TGSI code into D3D9 shader byte code. That's mostly an artifact of our device and I wouldn't be surprised if we changed that in the future to be closer to TGSI. The command set as a whole in the SVGA hardware is much closer to D3D than OpenGL. The hardware attempts to implement Direct3D semantics for most things. That's not to say that we view OpenGL as a second class driver, but this is all much easier if you pick one semantic to implement and our first 3D drivers were Direct3D so that won. Everything is communicated over a publicly documented binary protocol to the host.

          The process is:
          - The guest generates a series of commands (most of them are on the order of "draw primitives" or "set a bunch of texture states" or "create a texture")
          - The guest stuffs these commands into a FIFO ring buffer
          - The host interprets the commands and uses a host graphics API to accelerate them. On Workstation for Linux and Fusion for Mac, we use OpenGL in the backend and on Windows we use Direct3D or OpenGL if D3D isn't available for some reason
          - The host then reports completion of the commands to the guest

          This process allows everything to happen asynchronously. The guest can be generating commands while the host is processing commands it already has. We use fences to report completions of operations to the guest so that it knows when it may proceed. This protects access to memory that is shared between the guest applications and the virtual GPU. We've actually found a few applications that can run faster in the guest than directly on the host machine since we get to take advantage of an extra core or two in the process.

          As for using the driver in other virtual environments... I don't know. It's certainly possible but there's a fairly substantial body of code that makes up the 3D backends that would need to be implemented by the other virtualization vendors. Since the VMware SVGA device is relatively simple (fewer than 100 registers, most things are fifo commands) it would be much easier than virtualizing an R300 for example.

          Comment


          • #20
            FWIW ... SVGA, meaning "Super VGA", is not a VMWare term but an industry term. After VGA (640x480) hardware came Super VGA (800x600) which supposedly was to be replaced by XGA but really Super VGA stuck... even in Windows 7, my laptop uses the Super VGA driver (a generic high resolution driver)... this stuff used to be exciting, clearly I'm too old.

            Comment


            • #21
              Originally posted by Craig73 View Post
              FWIW ... SVGA, meaning "Super VGA", is not a VMWare term but an industry term. After VGA (640x480) hardware came Super VGA (800x600) which supposedly was to be replaced by XGA but really Super VGA stuck... even in Windows 7, my laptop uses the Super VGA driver (a generic high resolution driver)... this stuff used to be exciting, clearly I'm too old.
              Likewise with our "Super VGA" there's just been too much inertia to change it to something more... "interesting". We probably should have called it something else once we started having our own drivers.

              Comment


              • #22
                You could start telling everyone that SVGA stands for "Special VMWare Graphics Adapter" as someone suggested earlier

                Comment


                • #23
                  On http://www.x.org/wiki/GalliumStatus are there a lot of drivers.

                  Which do you think have the most interest to VMware, and therefore likely to be the first to get the "DONE" stamp?

                  And are there types of cards, that have more interest than others? Brand, speed, memory, power consumption?
                  Last edited by Louise; 11-17-2009, 02:49 PM.

                  Comment


                  • #24
                    We're definitely most interested in cards that are fast enough to be useful for games but I think that mostly stems from the fact that its much more satisfying to make a game work than to get Aero working. At the same time, we recognize that there are real uses for slower hardware in areas like 2D image processing and vector graphics. Heck, if WebGL or Google's O3D ever really take hold we might have a whole second coming of "3D web browsers" and such. We'd almost certainly want to accelerate that type of application.

                    Looking at the chart on the gallium status page you linked, I think VMware SVGA is on the wrong axis. The driver is for a device rather than a state tracker (devices are the rows, state trackers are the columns). That chart is sorta silly anyways, the whole point of gallium is that you don't need an OGL state tracker specific to each device. In theory, you only need a single state tracker for all devices.

                    Comment


                    • #25
                      Originally posted by alexcorscadden View Post
                      Looking at the chart on the gallium status page you linked, I think VMware SVGA is on the wrong axis. The driver is for a device rather than a state tracker (devices are the rows, state trackers are the columns). That chart is sorta silly anyways, the whole point of gallium is that you don't need an OGL state tracker specific to each device. In theory, you only need a single state tracker for all devices.
                      The intent was probably to indicate if the driver was complete enough to run each of the state trackers, since some require less functionality than others.

                      Comment


                      • #26
                        Originally posted by alexcorscadden View Post
                        We're definitely most interested in cards that are fast enough to be useful for games but I think that mostly stems from the fact that its much more satisfying to make a game work than to get Aero working. At the same time, we recognize that there are real uses for slower hardware in areas like 2D image processing and vector graphics. Heck, if WebGL or Google's O3D ever really take hold we might have a whole second coming of "3D web browsers" and such. We'd almost certainly want to accelerate that type of application.
                        I remember that there were a lot of speculation in the december time frame, what VMware would use Tungsten Graphics for.

                        One speculation I recall were OpenCL. That VMware wanted to virtualize GPU to offer render farms.

                        The article is here, but the forum link is dead...
                        http://www.phoronix.com/scan.php?pag...item&px=NjkyNw

                        Originally posted by alexcorscadden View Post
                        Looking at the chart on the gallium status page you linked, I think VMware SVGA is on the wrong axis. The driver is for a device rather than a state tracker (devices are the rows, state trackers are the columns). That chart is sorta silly anyways, the whole point of gallium is that you don't need an OGL state tracker specific to each device. In theory, you only need a single state tracker for all devices.
                        Jakob Bornecrantz have now fixed it, and updated it as well. You guys have been working hard!

                        Comment


                        • #27
                          Originally posted by alexcorscadden View Post
                          We're definitely most interested in cards that are fast enough to be useful for games but I think that mostly stems from the fact that its much more satisfying to make a game work than to get Aero working. At the same time, we recognize that there are real uses for slower hardware in areas like 2D image processing and vector graphics. Heck, if WebGL or Google's O3D ever really take hold we might have a whole second coming of "3D web browsers" and such. We'd almost certainly want to accelerate that type of application.

                          Looking at the chart on the gallium status page you linked, I think VMware SVGA is on the wrong axis. The driver is for a device rather than a state tracker (devices are the rows, state trackers are the columns). That chart is sorta silly anyways, the whole point of gallium is that you don't need an OGL state tracker specific to each device. In theory, you only need a single state tracker for all devices.
                          Would VMware consider writing a Direct3D state tracker so that they could have their graphics drivers built from Gallium for Windows/ReactOS?

                          Also, would it be possible in the future to entirely replace Mesa with Gallium3D? It seems with its capabilities to fail over to the softpipe rendering if hardware accelerated rendering can't do a certain thing is really good. Since there is a softpipe (which I assume is software rendering), it would replace Mesa quite well.

                          Comment


                          • #28
                            Mesa is what implements the OpenGL-like API, ie mesa is the "OpenGL state tracker".

                            Gallium3D replaces the Mesa hardware driver layer (src/mesa/drivers/dri/...), not Mesa itself.

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              Mesa is what implements the OpenGL-like API, ie mesa is the "OpenGL state tracker".

                              Gallium3D replaces the Mesa hardware driver layer (src/mesa/drivers/dri/...), not Mesa itself.
                              So a Direct3D state tracker could use Wine code to provide a D3D-like API?

                              Comment


                              • #30
                                Originally posted by King InuYasha View Post
                                So a Direct3D state tracker could use Wine code to provide a D3D-like API?
                                Not quite. The code in Wine is a Direct3D -> openGL wrapper.
                                Luckily, it can be used outside of wine. For example, VirtualBox only offers accelerated openGL to guests. If you need accelerated D3D on windows guests, you simply install wine's d3d-dlls and all d3d-calls are translated to accelerated openGL instructions.

                                In theory, that approach could work to provide a d3d-API on top of mesa on top of gallium3d, but there are two problems:

                                - wine's dlls are supposed to run in a windows-like environment. I don't know how many wine-dependencies you'd need to pull in as well, or if the dlls can even be compiled with linux calling conventions.
                                - going through openGL costs performance and correctness.

                                Sure, it can work, but eventually you'll want a real D3D state tracker that works on the bare metal. Of course, Wine's implementation and documentation can be used as a reference point, microsoft's documentation is often somewhat lacking.

                                Comment

                                Working...
                                X