vmware – scanlime

Graphics in VMware Fusion 3 and Workstation 7

I work on the graphics virtualization team at VMware. The company is about to release two new desktop virtualization products: Fusion 3.0 is in beta, with a release coming tomorrow. Workstation 7.0 has a public release candidate available.

There are a lot of exciting features in these releases, and my team has been working really hard on making the graphics virtualization in these releases the best we can. Our focus with these releases has been introducing a few large architectural changes in our graphics stack:

A brand new WDDM graphics driver for Windows 7 and Vista.

This is a complete rewrite, sharing no code with our Windows 2000/XP driver. This has been a monumental undertaking for the team, but the results have been pretty shiny. The architecture is clean and extensible, it’s much easier to understand and debug the driver’s performance, and it gives us a good platform to build on for future guest driver releases. Oh, and it can run 3D games with Aero enabled.

A brand new OpenGL driver for Windows guests.

Yes, this release has not one but two brand new drivers in it! The new OpenGL driver is based on Gallium, and it finally brings both major graphics APIs into VMware virtual machines. Both of our new drivers really deserve a blog post all to themselves.

We’ve been progressively rearchitecting the host-side infrastructure with a project we call “Better Unity and Multi-mon”.

Whereas previous releases of VMware’s products have implemented multi-monitor support and Unity mode on top of an architecture that was fundamentally designed for a single framebuffer, Fusion’s entire graphics stack has been overhauled in order to natively handle multiple screens, windows, and framebuffers. This architecture is common to all of our products, but so far only Fusion 3.0 has had its entire stack updated. Workstation and ESX still use a blend of new and legacy components.

As an end-user, the effects of our Better Unity and Multi-mon project are relatively subtle. Unity mode now renders much more efficiently, and applications like games and media players will run just as fast in Unity mode as they will in single window or fullscreen mode. Window resizing is smoother. We also have a high-quality GPU accelerated scaler which you can see in action on your VM’s live thumbnails in the VM Library window.

Screen Object

Back in April, I announced the VMware SVGA Device Developer Kit. This is an Open Source (MIT-style license) project which documents the virtual hardware interface that our graphics stack uses, and provides a simple reference driver and some examples. If you’re interested in operating system development, graphics, or virtualization, it can be a handy platform to experiment with, and it’s the best starting point if you’re trying to write a VMware graphics driver for a new operating system.

I’ve been trying to maintain the DDK with an open development process. Instead of periodically dumping code, all development takes place directly in the open repository. The one exception to this policy is for code which doesn’t work on released VMware products, either due to serious bugs or unreleased features.

As part of our architectural improvements for Fusion 3 and Workstation 7, we added a pretty big new feature to the SVGA device: “Screen Object”. Without Screen Object, the device has a single framebuffer with a geometry controlled by a set of registers. Multi-monitor support was faked by using an additional set of registers to carve up a single large rectangular framebuffer into individual monitors. With Screen Object, the guest can create “screens” dynamically, and they don’t necessarily need to be backed by any specific kind of memory.

A Screen is really an opaque non-guest-addressable memory object, just like an SVGA3D surface. If a Surface is analogous to a texture or a backbuffer, a Screen is analogous to a frontbuffer. You can blit between system memory and a Screen, and you can blit from Surface to Screen.

This is a simple concept, but it’s a powerful tool that can be used to implement a variety of different memory management and asynchronous rendering strategies. Last week I checked in a pretty big update to the DDK which includes refdriver support for Screen Objects, and 10 new Screen Object-only examples.

To run the examples, you’ll need Fusion 3 or Workstation 7. You’ll also need to manually enable Screen Object. Like many new features, we haven’t enabled Screen Object by default right away. It is enabled automatically for Vista, Windows Server 2008, Windows 7, and Mac OS X guests, since our drivers on those platforms may take advantage of the new features. For improved portability, it is disabled by default on other guest OS types. You can enable it manually by adding a line to your VMX file:

svga.enableScreenObject = TRUE

As always, the DDK is provided as-is, with no official support from VMware. So please don’t bug our support folks 😉 But I’ll try to answer questions as time permits if you send them to micah at vmware.com. Thanks!

Announcing the VMware SVGA Device Developer Kit

Over the weekend, I finally had time to release another work-related open source project: the VMware SVGA Device Developer Kit. It’s a set of documentation and example code for the virtual graphics card that’s present in all VMware virtual machines. The examples run on the (virtual) bare metal, so it’s a really easy way to experiment with low-level graphics driver programming.

3D Graphics at VMware

Despite all the random posts about helicopters and embedded systems on here, I haven’t really mentioned what I spend most of my time on these days…

I work in the Interactive Devices group at VMware. For people who aren’t familiar with VMware’s products, we do virtualization: software that lets you run multiple virtual computers inside your real computer. It’s good for data center management and consolidation, but I’m most interested in the ways virtualization can be used on the desktop: It’s great for running Windows apps on your Linux box, or running Windows/Linux software on your Mac using Fusion.

And that’s where our team comes in. While much of the company is focused on doing higher-level tools (user interfaces, management software, APIs) or on infrastructure that primarily benefits server products, our team is really in the heart of the virtualization technology that makes VMware tick on the desktop. We virtualize all the random desktop peripherals like the mouse, keyboard, video card, and sound card- but our team’s two big projects are USB and 3D graphics.

I’ve been working at VMware for close to 3 years now. I spent about the first half of that on USB. I did much of the work in implementing USB 2.0, and I did the original port of our OS-specific USB code to Mac OS X prior to the first release of VMware Fusion. I also implemented Isochronous transfer support (for web cams and the like), and did a lot of neat internal testing infrastructure.

I found VMware’s USB project really interesting because it meshed well with my prior experience with embedded systems and creating USB hardware. It was also a good introduction to the challenges in creating virtual hardware devices for a VM, particularly for hardware with such an un-virtualization-friendly architecture.

I still keep tabs on USB at VMware, but lately I’ve been pretty absorbed with our 3D virtualization effort.

For some background: VMware products provide their virtual machines with a “VMware SVGA device”, a made-up video card which provides legacy emulation of VGA and VESA BIOS modes, plus a vendor-specific set of 2D and 3D acceleration features. We provide drivers for this card as part of VMware Tools, and they come with recent versions of Xorg.

Our most recent releases of VMware Workstation and VMware Fusion include 3D acceleration support which is roughly on par with Microsoft DirectX 8.1, but it’s buggy in a lot of ways and it’s missing key features. Needless to say, the 3D team hasn’t been twiddling its thumbs. Our legal department won’t let me disclose exactly how much progress we’ve made or what features we will support in future products, but I can say that I’m very excited about our current work.

3D graphics virtualization is a really complex and interesting problem. Fundamentally what we’re doing is a Direct3D to OpenGL API translator (much like what the Wine project has) but it’s complicated by the fact that we also have to behave like a video card, and we also have to get the data into and out of a Virtual Machine efficiently. All said and done, the actual 3D API translation issues are only part of the story. There are also a lot of interesting resource management and synchronization problems.

It’s a really interesting project and we’re making some great progress, but we also have one big problem:

Our team is tiny. We have a substantial amount of work to do- it’s like writing a major 3D graphics driver (think ATI or NVidia), writing a game engine, and writing a complex interprocess communication system all rolled into one. Right now we have 7 developers on the project, and it feels like we could use 70.

So, if you know anyone who has a passion for 3D graphics, who knows low-level systems programming inside and out, who isn’t afraid of single-stepping through machine code in the debugger: take a look at our job postings (search for OpenGL) or send a resume to micah at vmware dot com.

Let the pixels flow

My posts have been pretty light on the photos recently- this is mostly just because I haven’t been taking a whole lot of pictures, but even when I had plenty of pictures they were safely quarantined behind gallery rather than flowing freely over my blog and all that aggregate it.

I admit, this photo has been slighly retouched. It was necessary to carefully adjust the gamma and color levels on this image to accurately capture reality, as my poor camera is just not capable of registering the sheer depth of this house’s color. I would not be surprised in the least if this house inspired the entire visual style of Edward Scissorhands.

I crossed paths with an older man just after taking this picture. He mentioned to me that the couple responsible for building this lovely little monstrosity died within just a few months of each other, and the house is on sale for a mere $1.3M or so. Of course, nobody’s buying it because it sits just north of the intersection of Sunnyvale Ave. and El Camino Real- not a particularly quiet road.

In other news, I’m at the Intel Developer Forum today, yesterday, and tomorrow. VMware had some extra tickets, and apparently my job isn’t time-critical enough that anyone thought twice about sending me. I apologize for taking almost no pictures of this event. There’s been a lot of cool hardware and a lot of slides with timing diagrams and artists’ conceptions of CPU architectures. Compared to SIGGRAPH, it’s quite visually dull. My only photo to report at the moment is of the expo floor, during their geekyness-contest that mostly involved a time trial at assembling and confuguring various computers using Intel ™ Technologies ™.

The hilight of my experience yesterday was the pair of sessions on Wireless USB. I’ve heard mention of the WUSB standard for a while now, but this was the first time I’ve heard details on the architecture. It’s great seeing them preserve nearly all software compatibility with USB, while changing some fundamental aspects of the protocol to keep radio link utilization high. Best of all, there was a whole section on WUSB on the expo floor featuring a lot of very preliminary but funcional hardware. I can’t wait for my $50 wireless EZUSB development kit in a few years.

I spent most of my time today in virtualization sessions. For those of you who haven’t been following their latest hype, Intel’s next chipset includes an extension called VT-x which basically handles virtualization of the CPU itself in hardware. This means that instead of doing lots of very complicated dynamic binary translation, like VMware does traditionally, the hardware is engineered to place the virtual machine monitor software in a completely new privilege level and fairly quickly swap out the entire CPU state when switching VMs.

It’s neat stuff, no doubt, but it’s only a small piece of the pie. It’s just a little annoying to see nearly all of Intel’s demo machines running VMware, but very little mention of the nontrivial tasks the VMM still has to perform using software like ours. Even with hardware support for CPU virtualization, the VMM needs to virtualize memory and some if not all I/O devices. Intel has plans for virtualization beyond just the CPU itself, but it will be a long long time before that comes close to the level of support VMware already gives in software.

Ah well. I’m curious what the virtual machine monitor folks at VMware have been doing with all this. I’d like to say I have a lot of inside information that I can’t share with you, but I really don’t know much at this point that didn’t become public at IDF today. I’ve been over in I/O-emulation-land where little of this is going to matter for at least a couple years.