Archive for October, 2007

Equalizer 0.4 released

30. October 2007

Finally a new Equalizer version! :)

Below is the release announcement:

Scalable Volume Rendering

We are pleased to announce the release of Equalizer 0.4, a framework for the development and deployment of scalable OpenGL applications. Equalizer 0.4 makes the programming of parallel OpenGL applications easier than before. Most notably, the new Programming Guide gathers all the information to write scalable Equalizer applications. Order your hardcopy today through lulu.com!

Many additions to the programming interface facilitate the conversion of existing, single-threaded OpenGL applications to parallel Equalizer-based programs. The support for volume rendering opens the power of scalable rendering to new markets, for example in medical imaging and Oil and Gas exploration. Furthermore, porting of existing rendering codes has been simplified substantially by the optional, per-node frame synchronization.

The full release notes for version 0.4 are available at:
www.equalizergraphics.com/documents/RelNotes/RelNotes_0.4.0.html

Commercial support, custom software development and porting services are available from Eyescale Software GmbH. Please contact info@eyescale.ch for further information.

Scalable Volume Rendering

25. October 2007

You gotta love volume rendering. :)

I colleague just benchmarked eVolve, the new Equalizer volume rendering example on a 16-node graphics cluster. You can see the performance graphs below (click on it for a large version).

Scalability of a 512^3 volume data set

The first one tests a 512x512x512, 8-bit data set. As mentioned in earlier posts in this blog, it’s a bad idea to overcommit GPU memory. ;)

As soon as the database decomposition makes the slice rendered by each node small enough, we’ll see a nice jump of performance, to interactive levels. From there on it scales nicely to 16 nodes. The 2D case is close enough to the linear scalability, given that it still needs to hold the full texture on all nodes.

Scalability of a 256^3 volume data set

The second benchmark uses the same data set at a 256^3 resolution. Since this is 1/8 of the data, we don’t see any caching effects. Scalability is also nice until it hits the IO limits of the system, which is an acceptable 25 fps at 1280×1024. And this is not yet the limit, the test used IP-over-IB instead of the fast SDP-over-IB because the system was not set up for it.

The 25 fps are reached with 12 nodes, adding more nodes does not improve performance. For database decomposition, the performance limit is 12.5 fps, since twice as much data has to be handled by each node (see the direct-send paper for details). This limit is reached at 10 nodes already.

Graphics Scalability on the Mac Pro

11. October 2007

Graphics Scalability on the Mac Pro

The other day I got my hand on a dual-GPU Mac Pro (ATI x1900, Quad-2.66 GHz, 10GB Ram) and quickly benchmarked two data sets with the new Equalizer polygonal renderer.

It’s pretty amazing what happens when you try to visualize more data than you can fit on the GPU. Apparently the drivers don’t do a very good job of paging the data in and out of GPU memory.

The first model I’ve benchmarked has 10 million triangles, rendered with Display Lists. On two cards there is a speedup of 2.3 (1.7->3.9 FPS) when dividing the work in screen-space, and a speedup of 3.77 (6.4 FPS) when dividing the database.

A small-ish data set of one million triangles showed, as expected, almost no scalability, running around 20 FPS.

When I find the time, I’ll do extensive testing and will write a proper white paper on the pitfalls of using a multi-GPU Mac Pro. Things I’ll cover are multi-view rendering for display walls (single- and multi-threaded), more data sets and a baseline using PCIe x16 (For the test above, both cards did run at PCIe x8).

Parallel Rendering ‘Hello, World!’

4. October 2007

Equalizer Hello, World running in a five-side CAVE™ configuration

I’ve just checked in a Hello, World! parallel rendering example to be released with Equalizer v0.4 .

It’s pretty cool to be able to have a VR-ready and cluster-ready OpenGL application in 150 lines of code, from which half of it are “sophisticated” OpenGL calls to draw six colored quads around the viewer.

On the right-hand side there is a little picture of a virtual CAVE™ mockup done with the screenshots of an Equalizer CAVE configuration and eqHello. Does a virtual VR installation qualify as V²R or VR 2.0? ;)

You can get the (compressed) SketchUP file here.

Subversion and Visual Studio Project files

2. October 2007

Somewhat off-topic, but does anybody know a proper solution to the problem that each Visual Studio instance seems to save project and solution files in a different way? (example)

My preferred solution would be a tool which loads the xml file(s) and saves them in a predefined order without changing the semantics of the files. This could be used as a pre-commit script to subversion, so that the source tree only ever sees a ‘unified’ version.

There has been some discussion on the QT list about this, but all the suggestions are workarounds which imo do not work in a distributed team.


Follow

Get every new post delivered to your Inbox.

Join 40 other followers