VMM-Independent Graphics Acceleration ∗

VMM-Independent Graphics Acceleration ∗ H. Andres´ Lagar-Cavilla Niraj Tolia University of Toronto Carnegie Mellon University [email protected] [email protected] M. Satyanarayanan Eyal de Lara Carnegie Mellon University University of Toronto [email protected] [email protected] Abstract 1. Introduction We have designed and implemented VMGL, an OpenGL virtualiza- Virtual machine monitor (VMM) technology has been put to many tion solution that allows graphics applications executing within vir- innovative uses, including mobile computing [16, 28, 40], system tual machines to leverage hardware rendering acceleration. VMGL management [17, 39], intrusion detection [18], and grid comput- is virtual machine monitor (VMM) independent, graphics process- ing [20]. However, the difficulty of virtualizing graphical process- ing unit (GPU) independent, and guest OS independent. VMGL ing units (GPUs) has so far limited the use of virtual machines provides suspend and resume capabilities across GPUs from differ- (VMs) for running interactive applications. The performance ac- ent vendors. Our experimental results from a number of graphics- celeration provided by GPUs is critical to high-quality visualization intensive applications show that VMGL provides excellent ren- in many applications, such as computer games, movie production dering performance, within 14% or better of that obtained with software, computer-aided design tools for engineering and architec- native graphics hardware acceleration. Further, VMGL’s perfor- ture, computer-aided medical diagnosis, and scientific applications mance is two orders of magnitude better than software rendering, such as protein modeling for drug synthesis. For this class of appli- the commonly available alternative today for graphics-intensive ap- cations, software rendering is the prevalent option for virtualized plications running in virtualized environments. Our results confirm execution, and it is unacceptably slow. VMGL’s portability across VMware Workstation and Xen (on VT Virtualizing GPUs is difficult for a number of reasons. First, the and non-VT hardware), and across Linux (with and without para- hardware interface to a GPU is proprietary, and many technical de- virtualization), FreeBSD, and Solaris. Our results also show that the tails are closely held as trade secrets. Hence, it is often difficult to resource demands of VMGL align well with the emerging trend of obtain the technical specifications necessary to virtualize a GPU. multi-core processors. Second, because the hardware interface is not public, GPU vendors make significant changes in the interface as their product lines Categories and Subject Descriptors I.3.4 [Computer Graphics]: evolve. Trying to virtualize across such a wide range of interfaces Graphics Utilities,Virtual Device Interfaces; C.5.m [Computer can result in a weak lowest common denominator. Third, the soft- Systems Implementation]: Miscellaneous ware needed to integrate a GPU into an operating system is typically included with the hardware as a closed-source device driver. General Terms Design, Performance, Experimentation In a virtualized environment, the driver is unusable for other guest operating systems. For reasons mentioned earlier, the technical de- tails necessary to create a new driver for other guests are typically Keywords Virtualization, Graphics, Hardware Acceleration, Porta- not available. In summary, virtualization of a hardware component bility, VMM-independence presumes the existence of a standard interface such as the x86 in- struction set, or the IDE and SCSI interfaces to disks; GPUs lack ∗ This research was supported by the National Science and Engineering such a standard. Research Council (NSERC) of Canada under grant number 261545-3 and a This paper proposes a solution that is strongly influenced by Canada Graduate Scholarship, by the Canadian Foundation for Innovation how applications actually use GPUs. Many of the virtualization (CFI) and the Ontario Innovation Trust (OIT) under grant number 7739, by challenges discussed in the previous paragraph would also com- the National Science Foundation (NSF) under grant number CNS-0509004, plicate the authoring of applications. For example, the absence of and by Google under the Summer of Code 2006 program. a stable GPU interface would require frequent application changes to track hardware. The large diversity of technical specifications across GPUs and the difficulty of obtaining them publicly would severely restrict the market size of a specific application implementation. The graphics community avoids these problems through the Permission to make digital or hard copies of all or part of this work for personal or use of higher-level APIs that abstract away the specifics of GPUs. classroom use is granted without fee provided that copies are not made or distributed Practically all applications that use GPUs today are written to one for profit or commercial advantage and that copies bear this notice and the full citation or both of two major APIs: OpenGL [5] and Direct3D [33]. Of these on the first page. To copy otherwise, to republish, to post on servers or to redistribute two, OpenGL is the only cross-platform API supported on all ma- to lists, requires prior specific permission and/or a fee. jor operating systems. For each supported operating system, a GPU VEE’07, June 13–15, 2007, San Diego, California, USA. Copyright © 2007 ACM 978-1-59593-630-1/07/0006. $5.00 vendor distributes a closed-source driver and OpenGL library. The job of tracking frequent interface changes to GPUs is thus delegated OpenGL, an open and cross-platform specification, and Direct3D, to the GPU vendors, who are best positioned to perform this task. a closed specification from Microsoft specific to their Windows Although OpenGL is a software interface, it has become a de facto platform. We describe OpenGL below in more detail. GPU interface. We therefore make it the virtualization interface. We describe VMGL, a virtualized OpenGL implementation that 2.2 OpenGL Primer offers hardware accelerated rendering capabilities to applications OpenGL is a standard specification that defines a platform-indepen- running inside a VM. VMGL runs the vendor-supplied GPU driver dent API for 3D graphics. The OpenGL API supports application and OpenGL library in the VMM host: the administrative VM for portability by isolating developers from having to program for a hypervisor like Xen, or the hosting OS for a VMM like VMware different hardware implementations. Workstation. The host runs a vendor-supported operating system Vendors implement the OpenGL API in the form of a dynam- and has direct access to the GPU. Using a GL network transport, ically loadable library that can exploit the acceleration features of VMGL exports the OpenGL library in the host to applications run- their graphics hardware. All OpenGL implementations must pro- ning in other VMs. When those applications issue OpenGL com- vide the full functionality specified by the standard. If hardware mands, the commands are transported to the GPU-enabled host and support is unavailable for certain functions, it must be implemented executed there. VMGL thus preserves complete application trans- in software. This isolates the programmer from having to determine parency; no source code modification or binary rewriting is nec- available features at runtime. However, the OpenGL specification essary. VMGL also supports suspend and resume of VMs running does allow for vendor-specific extensions; applications can only de- graphics accelerated applications, thus supporting several novel ap- termine the availability of these extensions at runtime. plications of VM technology [16, 28, 39]. Further, VMGL allows The OpenGL calls issued by an application modify the OpenGL suspended VMs to be migrated to hosts with different underlying state machine, a graphics pipeline that converts drawing primitives GPU hardware. VMGL is not critically dependent on a specific such as points, lines, and polygons into pixels. An OpenGL con- VMM or guest operating system, and is easily ported across them. text encapsulates the current state of the OpenGL state machine. We evaluate VMGL for diverse VMMs and guests. The VMMs While an application may have multiple OpenGL contexts, only include Xen on VT and non-VT hardware, and VMware Work- one context may be rendered on a window at a given time. OpenGL station. The guests include Linux with and without paravirtuali- is strictly a rendering API and does not contain support for user zation, FreeBSD and Solaris. In experiments with four graphics- input or windowing commands. To allow OpenGL contexts to in- intensive applications, including one that is closed source, the ob- teract with the window manager, applications use glue layers such served graphics performance of VMGL comes within 14% or bet- as GLX for X11-based systems, WGL for Microsoft Windows, and ter of native performance, and outperforms software rendering by AGL for the Macintosh. two orders of magnitude. Although this approach incurs the per- Today, OpenGL is the only pervasive cross-platform API for formance overhead of cross-VM communication, our experimental 3D applications. The competing proprietary API, Microsoft’s Di- evaluation demonstrates that this overhead is modest. Moreover, rect3D, only supports the Windows operating systems. OpenGL our results also show that multi-core hardware, which is increas- implementations are available for Linux, Windows, Unix-based ingly common, can help in reducing the performance

Load more