Announcement

Collapse
No announcement yet.

VirGL VirtIO 3D GPU Driver Added To Gallium3D

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

  • rabcor
    replied
    This is very interesting, I've been waiting for something like this to come along for years, thinking I'd have to do it myself one day even (really glad someone beat me to it) it's a shame that it only supports GL though (would be really nice to be able to run accelerated DirectX, not just GL programs on the guests)

    Doubt that it'll be goo enough for gaming for now (at least modern games) but a couple of years down the line on better hardware, it may work like a good emulator for old games (at that time, modern games now)

    Leave a comment:


  • gilboa
    replied
    Originally posted by justusranvier View Post
    Since I only run Linux guests, I stopped using emulated graphics devices in my guests in favor of making headless guests and connecting to the guest X sessions via xpra (which renders to Xvfb and has optional OpenGL support via VirtualGL)

    It will be interested to see how well/if xpra can be made to play with VirGL.
    Interesting solution.
    How's the performance? Can it run KDE or GNOME shell without killing the host / guest?

    - Gilboa

    Leave a comment:


  • justusranvier
    replied
    Since I only run Linux guests, I stopped using emulated graphics devices in my guests in favor of making headless guests and connecting to the guest X sessions via xpra (which renders to Xvfb and has optional OpenGL support via VirtualGL)

    It will be interested to see how well/if xpra can be made to play with VirGL.

    Leave a comment:


  • gilboa
    replied
    Originally posted by airlied View Post

    No. for Windows you need a WDDM kernel driver, and then a userspace Direct3D driver. The WDDM kernel driver would need to be written from scratch, the userspace D3D driver could reuse the gallium driver with a D3D(9,10).->gallium layer.
    Thanks for the info.

    - Gilboa

    Leave a comment:


  • andre30correia
    replied
    Originally posted by airlied View Post

    No. for Windows you need a WDDM kernel driver, and then a userspace Direct3D driver. The WDDM kernel driver would need to be written from scratch, the userspace D3D driver could reuse the gallium driver with a D3D(9,10).->gallium layer.

    ok nice job David

    Leave a comment:


  • zakhrov
    replied
    Will this replace the QXL driver?

    Leave a comment:


  • airlied
    replied
    Originally posted by zakhrov View Post
    Can this driver be cross compiled for Windows? I know the current qxl driver is available for windows but can we use virgl with Mesa's gallium-nine backend to bring direct3d acceleration in windows?
    No. for Windows you need a WDDM kernel driver, and then a userspace Direct3D driver. The WDDM kernel driver would need to be written from scratch, the userspace D3D driver could reuse the gallium driver with a D3D(9,10).->gallium layer.

    Leave a comment:


  • airlied
    replied
    Originally posted by MoonMoon View Post
    Does this mean it will work with proprietary drivers on the host machine?
    with some limitations, it only works with qemu in gtk/sdl mode on the screen. None of the egl/spice stuff will work with the current binary drivers. So with binary drivers it won't integrate well with libvirt.

    Dave.

    Leave a comment:


  • airlied
    replied
    Originally posted by schmidtbag View Post
    When benchmarks arrive, I would be really interested to see comparisons to bare metal (obviously), but also GPU/PCI passthrough of the host GPU being tested. That way we see whether the VM is the bottleneck or the drivers (or both).

    Seems like this is something that may need to be added to mesamatrix, too.
    Probably doesn't need much mesamatrix, since it is very dependant on what host drivers expose.

    For benchmarks I'd rather see benchmarks vs vmware and virtualbox running the same software on host/guest. Comparing virgl against pci passthrough is apples to oranges, they are different things, and have very different use cases. If you want speed and can give up the hw you use passthrough, if can't dedicate the hw you want something like virgl. It won't ever be close to native speeds, since there is always extra overheads.

    If you say run F23/gnome-shell in a guest inside a host running F23/gnome-shell, you have two compositors in the stack, along with the VM overheads. In theory you'd have to run a fullscreen app in the VM running in fullscreen on the host and hope the compositors get out of the way, then at least you just have the extra copies involved due to GL, as the guest app renders to a guest back buffer, swaps to a guest front buffer, the host side then copies the guest front buffer to a host back buffer and swaps that to get it on the screen.

    Dave.

    Leave a comment:


  • geearf
    replied
    This is really cool, thanks Dave!

    Leave a comment:

Working...
X