Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: VirtualBox Is Not Convinced About Gallium3D

  1. #1
    Join Date
    Jan 2007
    Posts
    14,370

    Default VirtualBox Is Not Convinced About Gallium3D

    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

  2. #2
    Join Date
    Jan 2008
    Posts
    772

    Default

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

  3. #3
    Join Date
    Aug 2009
    Location
    south east
    Posts
    341

    Default

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

  4. #4
    Join Date
    Aug 2008
    Location
    California, USA
    Posts
    196

    Default

    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.

  5. #5
    Join Date
    Aug 2008
    Posts
    99

    Default

    Quote Originally Posted by wswartzendruber View Post
    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.

  6. #6
    Join Date
    Feb 2010
    Location
    Canton, China
    Posts
    25

    Default

    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.

  7. #7
    Join Date
    Jul 2008
    Posts
    69

    Default

    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?

  8. #8
    Join Date
    Dec 2008
    Posts
    27

    Default

    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.

  9. #9
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    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.

  10. #10
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,126

    Default

    Quote Originally Posted by Remco View Post
    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.

Posting Permissions

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