This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Virtualization

VMGL brings 3-D effects to VMs

By Mayank Sharma on December 05, 2008 (8:00:00 PM)

Share    Print    Comments   

Virtualized computing environments can take advantage of built-in virtualization support in modern dual-core processors, but when it comes to 3-D acceleration in virtual machines, almost all fall flat on their faces. VMGL is a little-known application written as part of Google's Summer of Code 2006 program that lets OpenGL apps running inside a virtual machine take advantage of the graphics hardware acceleration on the host. It has limitations, but if you want 3-D in VMs, VMGL is your best bet.

The closest any virtualization platform has come to offering native 3-D in VMs is the recently released VMware 6.5 which lets you run OpenGL 2.0 apps in Windows XP guests. But it works only with certain ATI and Nvidia graphics, and not with on-board Intel graphics. This is a serious limitation, considering most recent Intel graphics have enough juice to power most shoot-'em-ups and racing simulators that run on Linux distros.

VMGL, on the other hand, works with all ATI, Nvidia, and Intel cards. Basically, if your host can do 3-D, then with VMGL so can your VMs. Another advantage in using VMGL is that it works across virtualization platforms. I've tried it on VMs virtualized by VMware and VirtualBox, and it should also work on Xen and KVM too.

VMGL runs apps (and games) that use the OpenGL library. The current version of VMGL supports OpenGL v1.5 with some exceptions that are mentioned in the document included in the source tarball. You can also install VMGL from the available RPMs.

You can run 3-D apps two ways in VMs using VMGL. The recommended method is to run a VMGL-modified VNC server in the VM and connect to it from the host. The second method is available only to VMware users, and because of its closed-source nature is fairly complicated. The VNC-method is easier to set up and works across virtualization platforms.

The easiest way to set up VMGL is by using the two RPMs -- one for the host distro and the other for the guest. On Debian-based systems, you can either use alien to convert the RPM file to .deb, or install VMGL from the tarball as documented in the bundled install file. You'll also need a few libraries (libXaw, libXext, libjpeg, libXmu) as well as their devel packages.

Once the dependencies have been satisfied and the packages installed, you need to tweak the Xorg configuration file on the guest distro to load the vmglext module. Edit the xorg.conf file (usually under /etc/X11) and under the Module section add the line:

Load "vmglext"

Save the file and restart X, then start the custom VNC server installed by VMGL, which if you installed the RPMs means issuing the Xvnc :1 command. If you have multiple VNC servers installed, make sure you are using the one provided by VMGL, which by default installs under /usr/local/bin.

Since the custom VNC server is based on an older release, it expects to find fonts under /usr/X11R6/lib/X11/fonts. You can work around this by either creating a symlink to the location of X11 fonts on your system (usually /usr/share/fonts) or starting Xvnc with the -fp switch followed by the path to the fonts, as in Xvnc -fp /usr/share/fonts/ :1.

Now head back to the host and use the VMGL-modified vncviewer (which by default installs under /usr/local/bin) to connect to the Xvnc server running on the guest. For instance, if the IP address of the guest VM is 192.168.2.55, vncviewer 192.168.2.55:1 will connect to the VM and open a window with a gray background, because the guest is running the Xvnc server without any apps.

Before you can run the apps, take note of the output in the window where you issued the vncviewer command. It'll say something similar to Set GLSTUB var in guest to point to port 7001. Head to the guest, and in a terminal window issue the command export GLSTUB=192.168.2.55:7001, replacing the IP address with your guest's address, and the port number with the one prompted by vncviewer.

You should now be all set. Run glxinfo in the guest; it should list vmgl as the glx vendor. Then compare the 3-D rendering speed between the guest and host by running glxgears on both. This isn't an exact benchmark but it gives you some numbers to compare. If you don't have glxinfo and glxgears, install the mesa-demos package for your distro.

Looking ahead

If VMGL doesn't run your favorite 3-D app, don't expect any quick updates, because the current priority for its author, H. Andrés Lagar-Cavilla, is to get his Ph.D. degree. But he does have some ideas to implement and is currently helping another developer implement Windows compatibility for VMGL, which will enable Windows guests to run 3-D apps on top of a Linux host.

Running 3-D apps via VNC with VMGL may look inconvenient at first, especially when you consider the fact that it currently works only on Linux guests over Linux hosts. But if you want your VMs to be as well equipped, graphically-speaking, as their hosts, there's no beating VMGL.

Share    Print    Comments   

Comments

on VMGL brings 3-D effects to VMs

Note: Comments are owned by the poster. We are not responsible for their content.

This is all well and good, but ...

Posted by: Anonymous [ip: 67.214.22.12] on December 06, 2008 06:47 PM
I'm not looking to run OpenGL apps in a Linux VM running on a Linux host. The current abilities of WINE notwithstanding, I'm looking to run Direct-X 9 apps running in a Windows VM on a Linux host with full acceleration. Not only would that allow me to play games easier, but it would sandbox things like SecurROM, as well as prevent a game from phoning the Mother Ship every time I play it (thanks to Host-only networking).

#

Re: This is all well and good, but ...

Posted by: Anonymous [ip: 79.117.114.84] on December 06, 2008 08:37 PM
Yes indeed, we all want that but you have to admit it's a step forward.

#

Re: This is all well and good, but ...

Posted by: Anonymous [ip: 69.206.171.69] on December 08, 2008 03:21 AM
The only way this would work would be able to rewrite the DX instructions into OpenGL. WINE has a partial re-implementation of many of the DX APIs which would undoubtedly be useful, unfortunately this would also yield the same DX limitations as WINE.

#

Re(1): This is all well and good, but ...

Posted by: Anonymous [ip: 65.25.150.64] on December 09, 2008 03:30 AM
There was a flap when Parallels for OS X did just that. They are using modified WINE sources as a D3D<->OGL bridge. They were a little iffy in the way they complied with the LGPL but the Wine devs seem to be content with what Parallels released.

BTW Parallels does a passable job with small 3D apps. I wouldn't attempt Crysis on it but I did run some Shockwave games and the Windows port of GLTron on it with OK performance.

#

Re: This is all well and good, but ...

Posted by: Anonymous [ip: 98.166.249.140] on December 17, 2008 12:31 AM
VMware can run Windows guest DirectX 9 applications on a Linux host. It's hardware accelerated using the OpenGL of the Linux host. It's not perfect but I use it all the time.

#

VMGL brings 3-D effects to VMs

Posted by: Anonymous [ip: 71.180.135.177] on December 09, 2008 08:23 PM
Unfortunately I am not a developer so my question is probably a dumb one, however I have wanted to ask it for a long time. Does a VM running on Linux have to have a GUI running using an X server? Would it be possible to have at start up of the VM that one would want to run say XP just to play a few Windows games to kill the X server and instead load the actual Windows graphic drivers inside the VM and then when you stop the VM to restart the X server. When someone is gaming they are not doing anything else on the system that requires a gui. Perhaps this is not technically possible but I have often wondered if this would be possible.

#

Re: VMGL brings 3-D effects to VMs

Posted by: Anonymous [ip: 66.203.52.45] on December 10, 2008 02:39 PM
I suppose it is possible but no extant VM software currently doesn't. It isn't as simple as killing X. The graphics card in the machine also displays the console. The state of the console would have to be preserved and restored by such a workaround. You'd probably want to extended guest tools since this would also put one out of touch with the host operating system. Also, the graphics card is still going to have PCI address space and registers reserved for it by the kernel whether it is in use or not. Any VM that wants to directly control host hardware has to have software written to deal with that as well. The guest would also have much more access to the host than VM software usually gives and that is a primary reason for reluctance to implement such things.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya