Originally posted by Craig73
View Post
Announcement
Collapse
No announcement yet.
VMware Releases Its New Gallium3D Driver
Collapse
X
-
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
-
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
-
Originally posted by alexcorscadden View PostLooking 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
-
Originally posted by alexcorscadden View PostWe'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.
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 PostLooking 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
-
Originally posted by alexcorscadden View PostWe'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.
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
-
Originally posted by bridgman View PostMesa 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
-
Originally posted by King InuYasha View PostSo a Direct3D state tracker could use Wine code to provide a D3D-like API?
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
Comment