Delegating OpenGL commands to host for hardware support in virtualized environments

Abstract

Today, the virtualization is a very important technology which is widely used in various area, from small mobile devices to virtual machine (VM) servers for large scale cloud computing. Now, hypervisor provides CPU and memory resources for the VMs with high performance like native machine through many researches on the virtualized environment. However, device virtualization techniques, especially those for GPU devices, are less studied than the other virtualization techniques. It is a chief obstacle to perform graphics processing in the virtualized environment. Since VM cannot access the physical GPU device directly, existing GPU device virtualization techniques have some limitations on 3D acceleration. Especially, those techniques spend more time to perform graphics processing because they use software rendering on the Mesa Software Fallback module in the guest OS. In this paper, we propose a GPU device virtualization technique that can improve OpenGL graphics performance. By using concurrent I/O request queue between the host emulation process and the guest OS, GPU device can be accessed directly. Our scheme can avoid graphics processing in the graphics stack of the guest OS and also can reduce vmexit overheads. The emulation process can perform the graphics processing using GPU hardware rendering. Our evaluation shows that the proposed technique has about 2.5x higher frame rate than existing Mesa software rendering.

Σvp

“…Clearly, emulating GPU code inside a virtualized emulation model yields suboptimal results. Nevertheless, this is still a common practice in many simulation frameworks of commercial products, which, for instance, use the Mesa open-source libraries to run OpenGL ES applications [8]. In fact, as shown by the last two rows of Table 1, running the C version of this program on either the CPU or the VP is faster than running the CUDA program on a GPU emulator inside a VP.…”

“…the Mesa software backend) [1,18]. The presence of an additional software layer on top of the VP significantly deteriorates the overall execution speed [8,20]. Fig.…”