Thursday Jan 08, 2009

Making 3D work over VNC

Dave recently played around with VNC on his computer and an iPod touch. While it worked surprisingly well, the achilles heel of many remote access solutions kicks in when you try doing some 3D stuff, such as a game, Second Life or maybe a scientific application.

This reminds me of one of the best kept secrets at Sun: We fixed the 3D-over-VNC problem.

International Supercomputing Conference 2008, LRZ booth showing 3D remote visualizationJust check out the Sun Shared Visualization Software, it is free and based on open source packages and it works like a charm. For example, here is a picture of the ISC 2008 conference in Dresden where you see a molecular visualization program in 3D stereo at the LRZ booth in Dresden, which is actually running in Garching near Munich.

That's right, the server runs in Munich, the client is in Dresden, there's more than 400km air line in between (probably close to double that in terms of network line) and we saw close to 30 frames per seconds of intricate molecular modeling madness that we could manipulate interactively like if the server was around the corner. In this case, the "server" was a supercomputer that fills the halls of the LRZ compute center, so it wouldn't quite fit the showfloor, thus they used Sun Shared Visualization to deliver the images, not the whole supercomputer, to Dresden.

And this is an increasingly common theme in HPC: As data amounts get bigger and bigger (Terabytes are for sissies, it's Petabytes where the fun starts) and compute clusters get bigger and bigger (think rows of racks after racks), your actual simluation becomes harder to transport (a truck is still the cheapest, fastest and easiest way to transmit PB class data across the nation). The key is: You don't need to transport your data/your simulation/your research. You just need to show the result, and that is just pictures.

Even if it's 3D models at 30 frames per second (= interactive speed) with 1920x1080 pixels (= HDTV) each frame, that's only about 180MB per second uncompressed. And after some efficient compressing, it boils down to only a fraction of it.

This means that you can transmit HDTV at interactive speeds in realtime across a GBE line without any noticeable degradation of image quality, or if you're restricted to 100 MBits or less, you can still choose between interactive speeds (at some degradation of picture quality) or high quality images (at some sacrifice in speed) or a mixture (less quality while spinning, hold the mouse to get the nicer picture). And this is completely independent of the complexity of the model that's being computed at the back-end server.

The Sun Shared Visualization Software is based on VirtualGL and TurboVNC, which are two open source projects that Sun is involved in. It also provides integration with the Sun Grid Engine, so you can allocate multiple graphics cards and handle reservations like "I need 3 cards on Monday, 3-5 PM for my presentation" automatically.

So, if you use a 3D application running on Linux or Solaris and you want to have access to it from everywhere, check out the Sun Shared Visualization Software for free and let me know what you've done with it. Also, make sure to check out Linda's blog, she runs the developer team and would love to get some feedback on what people are using it for.

P.S.: There's some subtle irony in the LRZ case. If you check their homepage, their supercomputer has been built by SGI. But their remote visualization system has been built by Sun. Oh, and we now have some good supercomputer hardware, too.

Tuesday Mar 06, 2007

Solaris 10 11/06 and NVIDIA video drivers: Missing symlinks

I recently learned that there's a small glitch in the combination of Solaris 10 11/06 and the latest NVIDIA drivers for Solaris on x64/x86 machines.

Apparently, there has been a change in packaging the MesaGL libraries in OpenSolaris which is also reflected in the Nevada and Solaris Express builds. But that change has not yet made it into Solaris 10 11/06.

This means that if you run Solaris 10 11/06 and install the latest NVIDIA drivers from their homepage, the symlinks that replace the MesaGL libraries with the hardware accelerated NVIDIA OpenGL ones will not be created correctly and thus your 3D applications will remain running slow.

See Bug 6530074 for details and a workaround. It contains a small script that will fix the symlinks and your 3D app should then be working fast again. Meanwhile, our NVIDIA driver team is working on a patch to fix the problem.


Tune in and find out useful stuff about Sun Solaris, CPU and System Technology, Web 2.0 - and have a little fun, too!


« April 2014