Release early, Release often

In this spirit, we’ve just started doing more regular developer releases. Version 0.5.1 is the first one, with the following new features:

- Statistics Overlay to understand and eliminate bottlenecks in the rendering pipeline
- Support for using Paracomp as a compositing backend, see README.paracomp
- Network-based instead of file-based model distribution in eqPly
- Support for the window swapsync hint on WGL

Full release notes are available at:
www.equalizergraphics.com/documents/RelNotes/RelNotes_0.5.1.html

Enjoy!

Parallel Rendering Timeline

On the right there’s a simple timeline of the most important toolkits for parallel rendering, naturally with more details for Equalizer.
I plan to extend this over time, and maybe even creating one with the major hardware milestones.
Any input is welcome - Skywriter VGXT, anyone?

ICC, GCC and OpenMP

Since a colleague finished the CPU-based alpha-compositing in Equalizer, it was time for another compiler benchmark round.

This time I used my MacBook Pro with an Intel Core 2 Duo 2.16 GHz, running Mac OS X 10.5.2. The compilers available were gcc 4.0.1, gcc 4.2.1 and icc 10.1.014. The latter two ones I tested with OpenMP disabled and enabled.
The results can be seen on the left (click on the picture for a large version). The upper graph shows the absolute throughput in MB/s for the performance-critical algorithms in Equalizer, and the lower the relative performance compared to the gcc 4.0.1 baseline.

Depth compositing assembles multiple color input images into an destination image based on the depth values. This is used for recombining the result of database decompositions of polygonal data.
Alpha compositing blends the results of volume rendering based on the alpha-value of the images.
Image compression is a RLE-like algorithm used to compress the images during network transfer.

For all tests only the basic optimization flag ‘-O2′ was used. I am sure that by tweaking the compiler flags and code, more performance can be squeezed out of the algorithm.
Nevertheless the results are interesting and representative, since I don’t have the time to investigate and maintain more complicated optimizations.
I think most programmers are under similar time constraints, and getting a 50-100% speed bump by just changing the compiler, and another couple of percents for adding a simple OpenMP pragma is quite valuable.

Good work Intel and the GCC-OpenMP team!

PS: Anybody has seen this bug with gcc and OpenMP?

Equalizer 0.5 released

As promised, here is the release of Equalizer 0.5:

We are pleased to announce the release of Equalizer 0.5, a framework for the development and deployment of parallel OpenGL applications. Equalizer 0.5 adds a number of features to increase the scalability, most notably pixel compounds for fill-rate-bound applications and a 2-4x performance increase during sort-last compositing. The Programming Guide has been extended to 43 pages and covers various new topics. Preview the content and order your hardcopy today at lulu.com!

Equalizer 0.5 now uses GLEW to provide easy-to-use OpenGL extension handling in parallel OpenGL applications. The new support for off-screen PBuffers on all platforms opens new use cases for Equalizer-based applications, for example seamless integration for scalability on multi-GPU workstations. Where available, image compression during network transfer has been accelerated using OpenMP.

The full release notes for version 0.5 are available at http://www.equalizergraphics.com/documents/RelNotes/RelNotes_0.5.0.html.

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

Equalizer 0.5 is coming

The Equalizer 0.5 release was planned for end of February, but then a couple of conferences got in between.

Now it is already April, and we are back to it. You can already get the programming guide, either as as a hardcopy or as a download, after filling out a short survey.

Have a look at the release notes to see what’s coming.

Stay tuned for the release!

Multi-GPU White Paper

I’ve just uploaded a white paper showing how much difference a parallel OpenGL application can make on a multi-GPU, multi-core workstation.

We have been able to increase the rendering performance from 5.2 frames per second to 20.7 FPS for the medium-sized data set, and from 2.1 FPS to 9.7 FPS for the large data set.

Get the PDF here.

Happy Birthday, Equalizer!

Three years ago today, I started at the University of Zürich with the goal to develop an open parallel rendering toolkit for the 21st century, using Equalizer as the project name.

In the last year, Equalizer made big steps in facilitating application porting, driven by the successful integration into a major commercial application. We broadened support to all major platforms, including a fully-featured port to Windows XP. Numerous other features, most notably support for volume rendering and substantial performance improvements, have established Equalizer as the parallel rendering framework for OpenGL.

What did happen in the first three years? The first six months I spent on research and gathering requirements, and then I needed over a year to lay the foundations. This year, culminating in the 0.1 release, was the hardest part. Since then it was lots of fun, with version 0.2 adding scalable rendering features, 0.3 supporting Windows XP and 0.4 adding volume rendering support and a programming guide. Version 0.5, which is just around the corner, will bring a whole bunch of new features, including pixel decomposition and increased performance.

Eyescale, the company behind Equalizer, also completed its first year of operations, exceeding our expectations by far, and the University of Zürich has put more resource behind the research around Equalizer. So I think it’s a safe bet to say that we have a very interesting year in front of us!

Asynchronous OpenGL Operations

Benjamin has a nice article on using secondary threads to offload some CPU-intensive operations.

I’ve played around with this some time ago with and created a small example for X11/glX-based systems, which I neglected lately. I’m sure some of you find Benjamin’s article useful, and may want to use glAsync as a starting point.

Parallel Ogre3D Follow-Up

Some time ago I mentioned that an Ogre3D-based Equalizer example application is coming.

Meanwhile I’ve integrated the code from Hui Chang into the Equalizer tree under src/contrib/eqOgre. Hui will be the one extending and maintaining this code. You can read about the progress in his blog.

I’m counting on him and the community to look after this. Occasionally I’ll test it on Mac OS X. Feel free to post to the eq-dev mailing list regarding eqOgre, either Hui or I will try to help you.

More on Depth-Based Assembly

It seems that 2008 will be the year of performance for Equalizer.

I’ve just commited the first version of CPU-based depth assembly to the Equalizer code base. The algorithm first assembles all images into a memory buffer on the CPU, and then transfers the result to the GPU using the default algorithm (GLSL in this case).

As you can see on the right, this algorithm is vastly faster than using the GPU. Each input image in this configuration adds about 4 ms to the total time, as compared to 18 ms for GLSL.

Since there is the static cost for setup and transferring the result (about 22 ms in the benchmark), the CPU-based algorithm makes only sense for more than one image, but becomes substantially faster as the number of input images grows. With four images, the new code is 4.5x faster than Equalizer 0.4, with eight images 6.4 times.

The benchmark used the same machine as in the previous posting. It has two 2.2 GHz Opteron CPU’s, but since OpenMP was not enabled, only one processor was used. OpenMP should accelerate this code path even more.