VirtualBox Is Not Convinced About Gallium3D

[phoronix]

Phoronix: VirtualBox Is Not Convinced About Gallium3D

While the VirtualBox virtualization platform that's owned by Oracle (formerly Sun) picked up OpenGL acceleration support for virtualized guest operating systems in late 2008 and then gained similar Direct3D support for VMs in early 2009, there's now an effort underway to try to get a Gallium3D driver developed...

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

[Ex-Cyber]

I think their reasoning makes sense in the short term. In the long term, though, it seems like a G3D driver would let them benefit from future improvements to Mesa with less work. Either way, it's probably a more strategic decision than can really be captured by a run-of-the-mill enhancement request (cf. the discussion over supporting proper tail calls in Java).

[squirrl]

Like saying don't throw the baby out with the bath water.

[wswartzendruber]

I really, really wish I had the expertise to write a KMS and Gallium3D driver myself. All I can do is offer to test code. Any other ideas? I'm open to writing them a letter on paper, if it will help.

[unix_epoch]

I really, really wish I had the expertise to write a KMS and Gallium3D driver myself. All I can do is offer to test code. Any other ideas? I'm open to writing them a letter on paper, if it will help.

One way to gain the expertise is to start trying. I learned a lot of C technique early in my programming career by working on a bunch of framebuffer-related stuff (the much weaker predecessor to KMS). Download the source code for your kernel and start hacking (apt-get source kernel-whatever, or just download a tarball from kernel.org). A reasonable place to practice might be figuring out how to change the boot logo.

[liangsuilong]

Maybe I can understand why virtualbox is not convinced about Gallium 3D. First, Gallium 3D is not perfect and needs more great improvements. Second, Gallium 3D is not open enough and still controlled by VMware although it is open-sourced. The last is WINE and WINED3D. VirtualBox's 3D acceleration relies on WINE and WINED3D largely. Now WINE gets not much gallium enhancements. So VirtualBox should follow WINE's step. But I believe VirtualBox will switch to gallium3d finallly if it is stable enough.

We should conside another virtualbox's implentment, such as better performance, better storage management, and better experience for teleportation. It is about five months since VirtualBox-3.1 released. Should Oracle be time to put out a new roadmap for Virtualbox? I am so urgent to read some information about the next major version VirtualBox.

[jbrown96]

I figured that I could figure this out over time, but I have been completely unable to figure it out. What is a state tracker?

[uwgandalf]

the state trackers reside on top of the gallium3d framework, they're sort of plugins and can provide opengl, direct3d, vdpau etc. all in a graphics card agnostic way. So not every driver has to reinvent a particular function, because the graphics card itself is abstracted in a lower region of the gallium3d framework. So a change/improvement to a opengl state tracker, means gains for all the gallium3d drivers out there.

[Remco]

A state tracker is a software library that uses Gallium3D to accelerate certain computations. For these computations, it sends G3D commands to the graphics driver. These G3D commands are then executed by the graphics driver (if it understands G3D commands). So, in the case of OpenGL, the state tracker will send vertices, textures, shaders to the graphics card as Gallium3D commands.

The reason for this separation, is that any graphics driver only has to implement Gallium3D. The state trackers will then work on any such graphics driver. So you only have to write OpenGL once. And once you have a driver that understands Gallium3D, you automatically support any state tracker that's out there.

A state tracker can expose OpenGL, OpenCL, OpenGL ES, WebGL, OpenVG, Render, Direct3D, CUDA, Cairo, YourMomma... any API you would like. Currently, I know of state trackers for OpenGL 1.5, OpenGL ES, and OpenVG.

In the case of virtualization, Gallium3D can be used to reduce the amount of work that's needed. You create a simple passthrough driver which passes Gallium3D commands to the host. Then, magically, your Linux guests will have acceleration for any state tracker. If your guest is Windows, you'll need to create a Direct3D state tracker and a passthrough driver. This is pretty much the same amount of work that you had to do anyway, so for Windows support Gallium3D doesn't help much.

This is all outsider's knowledge, so correct me if I'm wrong.

[BlackStar]

A state tracker is a software library that uses Gallium3D to accelerate certain computations. For these computations, it sends G3D commands to the graphics driver. These G3D commands are then executed by the graphics driver (if it understands G3D commands). So, in the case of OpenGL, the state tracker will send vertices, textures, shaders to the graphics card as Gallium3D commands.

The reason for this separation, is that any graphics driver only has to implement Gallium3D. The state trackers will then work on any such graphics driver. So you only have to write OpenGL once. And once you have a driver that understands Gallium3D, you automatically support any state tracker that's out there.

A state tracker can expose OpenGL, OpenCL, OpenGL ES, WebGL, OpenVG, Render, Direct3D, CUDA, Cairo, YourMomma... any API you would like. Currently, I know of state trackers for OpenGL 1.5, OpenGL ES, and OpenVG.

In the case of virtualization, Gallium3D can be used to reduce the amount of work that's needed. You create a simple passthrough driver which passes Gallium3D commands to the host. Then, magically, your Linux guests will have acceleration for any state tracker. If your guest is Windows, you'll need to create a Direct3D state tracker and a passthrough driver. This is pretty much the same amount of work that you had to do anyway, so for Windows support Gallium3D doesn't help much.

This is all outsider's knowledge, so correct me if I'm wrong.

The problem is that you need to translate TGSI back into something the host machine can understand and execute. Systems that can interpret TGSI directly are virtually non-existent right now on Linux (and completely non-existent on Windows and Mac OS X hosts).

VirtualBox sends OpenGL commands to the host to execute, which will work as long as the host has an OpenGL driver. That's the sensible approach and I'm glad to see they are pursuing it. Were they to use Gallium, they'd have to translate TGSI back into OpenGL on the host side, which will likely be slower and less compatible than the current approach.