Announcement

Collapse
No announcement yet.

VMware Releases Its New Gallium3D Driver

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

  • phoronix
    started a topic VMware Releases Its New Gallium3D Driver

    VMware Releases Its New Gallium3D Driver

    Phoronix: VMware Releases Its New Gallium3D Driver

    Last Friday during the Gallium3D workshop we learned that the Tungsten Graphics developers that were bought out by VMware have been working on a virtual Gallium3D driver that would be used by guest operating systems running within VMware's virtualization platform. This is especially interesting considering that it will allow virtualized guests to have accelerated access to X11, OpenGL, OpenCL, X-Video, XvMC, and all sorts of other possibilities that's just limited by what's supported by the available state trackers. This afternoon Jakob Bornecrantz has pushed out this initial Gallium3D driver for use in VMware guests...

    http://www.phoronix.com/vr.php?view=NzcxMQ

  • MostAwesomeDude
    replied
    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 chart is to separate theory from practice, because in practice, a lot of state tracker/driver combinations don't work right or aren't conformant. I wanted to make sure that people were aware of deficiencies and bugs in implementations; in particular, I'm kind of tired of no good way to test OGL conformance and I would rather be embarrassed by a status page than annoyed by bug reports.

    You may notice how the nouveau devs are not editing the page. :3

    ~ C.

    Leave a comment:


  • rohcQaH
    replied
    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.

    Leave a comment:


  • King InuYasha
    replied
    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?

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • King InuYasha
    replied
    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.

    Leave a comment:


  • Louise
    replied
    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!

    Leave a comment:


  • Yuma
    replied
    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.

    Leave a comment:


  • alexcorscadden
    replied
    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.

    Leave a comment:


  • Louise
    replied
    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, 03:49 PM.

    Leave a comment:

Working...
X