Home > Blogs > VMware Fusion Blog

VMware Fusion 301: Control of Hardware, part 1

Last week when I wrote about what Tools generally does and mentioned that it enabled 3D acceleration, someone asked a natural question: What makes 3D acceleration in a virtual machine so hard? Why can’t the guest directly control the graphics card?

To answer this requires a bit of explanation. One key thing to keep in mind is that the host OS has control of the hardware. We are subject to the limitations and bugs of the host drivers, just like any other OS X program. As an example, if a host application or kernel extension won’t release a USB device, you won’t be able to use it in a virtual machine. As another example, updating the version of OS X on the host (and therefore the graphics drivers) can fix rendering bugs in guest 3D.

As I mentioned before, most hardware expects to be controlled by exactly one OS. The OS is sort of like a traffic cop, deciding when to draw things on screen, write things to disk, and so on. Suppose a device has a resource of a certain size. This happens all the time – maybe RAM for the system, a ring buffer for a network card, video RAM for a graphics card, or almost anything. OSes assume they’re the ultimate arbiters of the system (because normally they are), and want to use as much resources as possible (unused resources are wasted resources).

Thought experiment time: what if two OSes could try to control a resource at the same time? Keep in mind the guest and host don’t really know about each other – the guest can’t see what the host is doing, and (without trickery like Tools), the host can’t figure out what the guest is doing. Say the host uses up half the video RAM — managing windows, playing that movie trailer you have open, and so on. Along comes the guest and wants to use all the video RAM for a game in the guest. What happens? In the worst case, the host and guest will scribble over each other (thinking they’re in full control) and you’ll end up with garbage on the screen, if not a full kernel panic.

In addition to the OSes interfering with each other, a related problem is the devices themselves. Again, in a normal system, there’s only one OS, so they expect to only be receiving commands from one source which knows what it’s doing. Devices can have state (e.g. one command can be affected by previous commands), and as long as there’s only one OS that knows what it’s doing, things are fine. However, throw in another OS that has no idea of the first one’s state (or vice versa) and things will rapidly break as the device’s idea of the state and the OSes idea of the state diverge.

Hopefully you can see why multiple OSes can’t control the same device at the same time — too many cooks spoil the broth.

At this point, there are two natural questions: What if the OSes and devices got smarter? What if the OSes were not trying to control the same device, e.g. what about multiple graphics cards, say on a Mac Pro or one of the new MacBook Pros? I’ll address these questions in future posts.

One thought on “VMware Fusion 301: Control of Hardware, part 1

  1. CJ

    Wow, the prospect of using both graphics chips in the new MBPs is very interesting. I guess that won’t be possible until Apple makes it so Mac OS X can use them both, though.
    Obviously it would be unrealistic to expect VMware fusion to have the same kind of 3D graphics speed as a native Mac app, but can we expect the performance to improve over time?
    Most games I try to run in Fusion now tell me they require better hardware. I understand games aren’t the main purpose of the program, but it is a very neat bonus that (I think) many would buy the app for.
    I guess I am just looking for someone to say that 3D acceleration improvements are in the pipeline before I make a purchase.


Leave a Reply

Your email address will not be published. Required fields are marked *