VMware To Overhaul Their Virtual Graphics Driver

[gilboa]

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

[RealNC]

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.

[gilboa]

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.

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

[RealNC]

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.

[curaga]

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

[gilboa]

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

[smitty3268]

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.

[allquixotic]

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.

[project_phelius]

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?

[allquixotic]

Yay! Finally! It's been many many months that vmwgfx has been completely broken for me using the latest stable VMware Workstation. I'd love to see that change, and have it support Unity, Gnome-Shell+Mutter, and Wayland. That way, anyone with a properly functioning host-side 3d stack should be able to test, develop apps for, and enjoy the new compositing environments inside a guest.

This also means that folks whose only viable driver stack entails running Windows or a proprietary driver on Linux can now see how KMS, Gnome-Shell, Unity and Wayland work. Since the vmwgfx code in the guest has no direct interaction with the host-side (it's all passed through a proprietary hypervisor layer), you should be able to determine how well your host-side driver complies with their hypervisor translation layer by testing out a few Direct3D games on a Windows guest. If that pans out well, you'll likely see good results once they fix vmwgfx guest-side.

Also, I know a lot of corporations that want to do dual development for Windows and Linux products, or they want to provide their engineers with a Windows environment to use MS Office and Outlook, but have them do actual development on Linux. For these people, the typical solution is to give them a KM (keyboard and mouse) switch with two monitors, and two computers: one running Linux and one running Windows. This just seems... ugh, wasteful: energy costs, and two computers for each engineer.

Those sorts of organizations could save a lot of money by just doubling the RAM in each computer and buying an organizational VMware Workstation license. Once vmwgfx is viable, you can run a Windows host for your everyday needs (Corporate intranet that only works on IE, Outlook, Visio, etc) and a Linux guest with full 3D accel and support for the latest distros. Put the guest in full screen mode and stick it on one of your monitors, and plug both monitors into one computer. Then you can sell, decommission or play with the spare second computer until they break, and just keep upgrading the one computer for the future. And I'm pretty sure the cost of extra RAM and a workstation license (purchased with a volume discount) is less than buying a whole second workstation, especially considering that developer computers are already pretty high-end at most places.

Wow, a real business case for running a Gallium3d driver, that could save about $1000 - $2000 every few years (each time the computers are due for a refresh) for each developer in an organization. Maybe a big VMware customer will request that VMware start to more robustly support higher OpenGL versions in vmwgfx, and that might lead to better support overall in Mesa?! Eh, wishful thinking, but I really hope so. The unfortunate part is that, out of all the organizations that would love to use this kind of setup, 90% of them probably don't even need advanced 3D acceleration, and are perfectly happy with the shipped 2D-only driver you get from the Linux guest additions.