Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31

Thread: VMware Releases Its New Gallium3D Driver

  1. #21
    Join Date
    Jun 2008
    Location
    Palo Alto, CA
    Posts
    8

    Default

    Quote 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.

  2. #22
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

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

  3. #23
    Join Date
    May 2008
    Posts
    598

    Default

    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 at 02:49 PM.

  4. #24
    Join Date
    Jun 2008
    Location
    Palo Alto, CA
    Posts
    8

    Default

    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.

  5. #25
    Join Date
    Mar 2009
    Posts
    14

    Default

    Quote 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.

  6. #26
    Join Date
    May 2008
    Posts
    598

    Default

    Quote 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

    Quote 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!

  7. #27
    Join Date
    Jul 2007
    Posts
    53

    Default

    Quote 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.

  8. #28
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,284

    Default

    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.

  9. #29
    Join Date
    Jul 2007
    Posts
    53

    Default

    Quote 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?

  10. #30
    Join Date
    Nov 2008
    Posts
    755

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •