Announcement

Collapse
No announcement yet.

VMware To Overhaul Their Virtual Graphics Driver

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

  • phoronix
    started a topic VMware To Overhaul Their Virtual Graphics Driver

    VMware To Overhaul Their Virtual Graphics Driver

    Phoronix: VMware To Overhaul Their Virtual Graphics Driver

    Two weeks ago I extensively talked about VMware's Linux graphics driver used by their virtualization products. To provide graphics hardware acceleration support within VMware guest instances, they have an elaborate (and open-source) driver stack complete with the upstream kernel DRM module and a Gallium3D user-space driver. This driver has been around since 2009, but it's about to be overhauled by VMware and it will bring some interesting changes...

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

  • gilboa
    replied
    Originally posted by RealNC View Post
    If we were talking about an emulator, then yes, I would agree with you. But for virtualization? No. The whole point of this is to give the guest system access to the host hardware as much as possible through paravirtualization. The host OS needs to be able to cope with the results. With that logic, VMWare should not give direct access to the host CPU, because guest software might crash it.
    Guess it depends on your use case: Are you an enterprise user or a home user.
    While a home user usually don't worry about host/guest stability or guest separation, an enterprise users usually require a "Chinese wall" between the different guests and the host.

    Now given the fact the 3D is usage is no longer limited to gaming - but slowly becoming a baseline requirements for many deployments - even enterprise ones, I would guess that all the major players (VMWare, Oracle, RedHat and Microsoft) spend most of their time on getting an acceptable 3D solution that's capable of running Windows 7 w/ Aero enabled in a mass desktop consolidation cluster, as opposed to a running Crysis under a virtualized copy of Windows 7.

    Never the less, I do agree with you that for personal usage, a direct pass-through is an acceptable solution.

    - Gilboa

    Leave a comment:


  • RealNC
    replied
    Originally posted by gilboa View Post
    In theory, you are correct, but in reality, the complexity of memory management within GPU drivers makes them a prime source of memory corruption related crashes.
    This isn't something that VMWare, or any other virtualization software, needs to concern itself about. The OS gives some guarantees to the software that runs in it. And one of them is that unprivileged code can't crash the machine.

    What I'm trying to say is this: VMWare is just a program like anything else. There's nothing special about it. If Sauerbraten (or any other game) can crash your machine, there's no reason VMWare shouldn't, or couldn't. From the host driver's point of view, both are OpenGL clients.

    If we were talking about an emulator, then yes, I would agree with you. But for virtualization? No. The whole point of this is to give the guest system access to the host hardware as much as possible through paravirtualization. The host OS needs to be able to cope with the results. With that logic, VMWare should not give direct access to the host CPU, because guest software might crash it.

    Leave a comment:


  • gilboa
    replied
    Originally posted by RealNC View Post
    No, it will not. Drivers are not supposed to crash your system when running unprivileged processes, no matter what you send them.
    In theory, you are correct, but in reality, the complexity of memory management within GPU drivers makes them a prime source of memory corruption related crashes.
    Once you let the guest direct access to the host's 3D stack, any minor bug, insufficient marshaling, or any minor DOS-open code-path within the host driver will automatically take down the host, taking all over guests with it. Far worse, bugs within the driver memory management / request marshaling can be used to let one rough guest see memory blocks belonging to other guests.

    Originally posted by curaga View Post
    If a GPU crashes hard, doesn't it often take the PCI(-E) bus with it? Thus even separate gpus might not save you...
    ** I'm not a PCI-E expert **
    As far as I know if you're using IO-VT capable hardware, even if you somehow misconfigure or trash the PCI configuration space of a certain device, it should not effect other devices.
    Then again, I've got very limited experience in dealing with PCI/PCI-express.

    - Gilboa
    Last edited by gilboa; 05-29-2011, 08:49 AM.

    Leave a comment:


  • RealNC
    replied
    Originally posted by gilboa View Post
    The first and foremost requirement of any virtualization solution that no guest error / crash can ever penetrate and bring down the host.
    Once you start doing direct 3D pass-through without any type of marshaling, a malformed Direct3D or OpenGL call can and will bring down the host.
    No, it will not. Drivers are not supposed to crash your system when running unprivileged processes, no matter what you send them.

    Leave a comment:


  • curaga
    replied
    If a GPU crashes hard, doesn't it often take the PCI(-E) bus with it? Thus even separate gpus might not save you...

    Leave a comment:


  • gilboa
    replied
    Originally posted by project_phelius View Post
    Been drooling for vmware/oracle/Xen to do something like
    Parallels workstation 4 extreme.
    we all want (near-)native 3d performance in our VM's.

    Who's gonna bring this to consumer level desktops/laptops first and what's the ETA ???

    Is directx(or opengl) over gallium be the solution to this problem?

    How is it that wine seems to get better 3d performance than vmware/virtualbox sometimes?
    The first and foremost requirement of any virtualization solution that no guest error / crash can ever penetrate and bring down the host.
    Once you start doing direct 3D pass-through without any type of marshaling, a malformed Direct3D or OpenGL call can and will bring down the host.
    Beyond that, virtualized 3D more-or-less requires that multiple guests will be able to run 3D application simultaneously which makes pass-through 3D even more complicated.

    As other pointed out, in the short term, wine is a far better option.
    In the long term, I would imagine that a combination of multiple GPU cards, pass-through-PCI capable drivers and smart management will give host-like performance to guests, without endangering the stability of the host.
    On my side, I'm waiting for the full integration of Xen PCI-backend to the 2.6.40 kernel and hopefully, nVidia binary support for Xen. (E.g. use low-end GPU for the host, and let the guests use the high-end GPU's)

    - Gilboa

    Leave a comment:


  • smitty3268
    replied
    Originally posted by project_phelius View Post
    How is it that wine seems to get better 3d performance than vmware/virtualbox sometimes?
    To put it more simply, WINE is not an Emulator. It's a native re-implementation, which means it has none of the overhead associated with running a second operating system on virtual hardware and passing calls between them.

    Leave a comment:


  • allquixotic
    replied
    Originally posted by project_phelius View Post
    How is it that wine seems to get better 3d performance than vmware/virtualbox sometimes?
    This shouldn't be hard to understand: it's a question of architecture complexity.

    Full virtualization such as VMware, a 3d call goes something like this: Guest userspace application -> guest kernel -> hypervisor -> x86 code interpreter and/or Intel hardware "VT" extensions -> host kernel -> host userspace -> 3d stack (Direct3D or OpenGL) -> host kernel -> GPU. I'm pretty sure you have to enter and leave the host kernel at least twice, because on the host-side the only stable 3d graphics API you have is in userspace, in the form of the OpenGL or Direct3D userspace libraries. But the call is translated and passed through the host kernel by the hypervisor, so that's another kernel call. In all, you have a (virtual) context switch in the guest, and two physical context switches on the host. Yuck.

    Wine emulation, a 3d call goes something like this: Win32/PE executable interpreter -> decode Direct3D or OpenGL call -> translate call to host-side native call -> make call -> kernel -> GPU. You only need as many kernel context switches as you'd have with a native Linux/ELF application calling OpenGL. Even if you're emulating Direct3D, the worst kind of finagling you could possibly need would be to make a large number of OpenGL calls to emulate Direct3D behavior. But then, wouldn't a Hypervisor implementation have to make an equally high number of calls to emulate D3D when the host-side uses OpenGL?

    A properly implemented wine should be able to outperform a full VM any day of the week, but in the general case, a full VM should prove to be more reliable and more faithfully run applications. Because using the official Windows kernel and userland from a real install of Windows will yield you more reliable results than emulation, because you are using the same (bitwise exact) Microsoft kernel and libraries that the game developer tested their game against. As long as the hypervisor developers have sorted out their 3d stack, it should work 100%. But the performance will suck until CPU and GPU developers put their heads together and come up with some kind of direct GPU call passthrough for guests, similar to what they did with VT-d for I/O.

    Edit: By the way, VMware's drivers that support 3D acceleration in Windows guests are completely separate from vmwgfx, as far as I know. So the entire discussion involving Windows emulation / virtualization is completely off-topic. vmwgfx is only about running Linux guests (regardless of what the host OS is). Not even Solaris/BSD. It only supports operating systems that can run the KMS+TTM+GEM stack in the kernel, which to date is only Linux.
    Last edited by allquixotic; 05-26-2011, 12:58 PM.

    Leave a comment:


  • project_phelius
    replied
    All fine and dandy, but where's our VGA passthrough?

    Been drooling for vmware/oracle/Xen to do something like
    Parallels workstation 4 extreme.
    we all want (near-)native 3d performance in our VM's.

    Who's gonna bring this to consumer level desktops/laptops first and what's the ETA ???

    Is directx(or opengl) over gallium be the solution to this problem?

    How is it that wine seems to get better 3d performance than vmware/virtualbox sometimes?

    Leave a comment:

Working...
X