Announcement

Collapse
No announcement yet.

VMware Releases Its New Gallium3D Driver

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

  • #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
      Test signature

      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; 17 November 2009, 03: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...
              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


              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.
                  Test signature

                  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