Archive for the ‘Equalizer’ Category

IEEE VisWeek: Equalizer poster

16. October 2012

Equalizer Poster


Tomorrow night is the poster session for the second poster, recent advances in Equalizer: Region of Interest, Focus Distance, Optimizations for Multi-GPU Clusters (Thread Affinity, Asynchronous Readback) and new applications.

The poster is already up in Ballroom A, or on the right side.

The DASH poster reception went very well, everybody I talked was convinced by the concept and saw immediate applicability for their problems. The feedback was much more positive than I was hoping for.

Equalizer 1.4 released

7. September 2012


The last two weeks have been quiet, since I was on biking through Switzerland. Meanwhile, poor Daniel back at work churned through most of the Collage changes outlined in the last post. You can see the changes in the Collage endian branch on github, which will be merged back into master in the next couple of weeks.

Now back to the news: After finally figuring out how to build Equalizer and dependencies using MacPorts portfiles on Mac OS X, I released the long-standing 1.4 version of Equalizer, GPU-SD, Lunchbox and vmmlib. Below is the release announcement – enjoy!

Neuchatel, Switzerland – September 7, 2012 – Eyescale is pleased to announce the release of Equalizer 1.4.

Equalizer is the standard framework to create and deploy parallel, scalable 3D applications. This modular release includes Collage 0.6, a cross-platform C++ library for building heterogenous, distributed applications, GPU-SD 1.4, a C++ library and daemon for the discovery and announcement of graphics processing units using zeroconf networking and Lunchbox 1.4, a C++ library for multi-threaded programming. All software packages are available for free for commercial and non-commercial use under the LGPL open source license.

Equalizer 1.4 is a feature release extending the 1.0 API, introducing major new features, most notably asynchronous readbacks, region of interest and thread affinity for increased performance during scalable rendering. It culminates over seven years of development and decades of experience into a feature-rich, high-performance and mature parallel rendering framework and related high-performance C++ libraries.

Equalizer enables software developers to easily build interactive and scalable visualization applications, which optimally combine multiple graphics cards, processors and computers to scale the rendering performance, visual quality and display size.

Equalizer Applications

Eyescale provides software consulting and development services for parallel 3D visualization software and GPU computing applications, based on the Eyescale software products or other open and closed source solutions.

Please check the release notes on the Equalizer website for a comprehensive list of new features, enhancements, optimizations and bug fixes. A paperback book of the Programming and User Guide is available.

We would like to thank all individuals and parties who have contributed to the development of Equalizer 1.4.

Left image courtesy of Cajal Blue Brain/ / Blue Brain Project. Second from left copyright Realtime Technology AG, 2008. Right image courtesy University of Siegen, 2008.

Introducing Collage: github

3. August 2012

Collage

Collage Dependencies

Good news, everybody: Since this week, Collage is a separate project on github.

First this means that it’s much more lightweight to use since it has a small source code and repository size (<10MB) and less dependencies compared to the full Equalizer project. Say hello fast compilation times (less than a minute on my slowish laptop), easy setup and simpler directory layout.

Second this means that the next version will have a well-defined, stable API, similar to what Equalizer already has. I’m steadily working toward this with good progress and lots of cleanup. This means that building and maintaining distributed applications based on Collage will be painless.

Third and last my hope is that this gives the project more visibility and credibility, and therefore more outside contributions. We’ve already had quite a few awesome ones in the past, such as InfiniBand RDMA and UDT support.

Edit: API documentation can be found on eyescale.github.com.

Introducing Collage: Barrier

15. July 2012

While I personally think that barriers are an anti-pattern, they have exactly one valid use case in my line of work — as swap barriers synchronizing the display of a new frame across multiple segments of a display wall or immersive installation.

In an ideal work, swap synchronization would be done using hardware support. Equalizer supports this for nVidia G-Sync, but I haven’t seen many installations using hardware swap synchronization. First, it’s expensive since you need a professional grade card with a special synchronization board. So lower cost installations such as display walls typically don’t even have the hardware. Installations which need the frame synchronization, such as active stereo setups, oftentimes only use the frame (retrace) synchronization and use a software barrier for swap synchronization. The reason is that getting hardware swap synchronization running is such a mess due to driver issues that most people don’t bother. For these reasons, Equalizer both supports hardware and software swap synchronization. The software synchronization used a co::Barrier.

Back to the Collage barrier: Once it is set up, the only call needed is enter, which will block until the height has been reached.

Barriers are versioned, distributed objects. Any process can set up a barrier, register it and communicate the barrier identifier and version to all users of the barrier. The users map, sync and enter the barrier. Since it’s versioned, the master instance can be committed any time, and enter requests are versioned, that is, a barrier operation for an old version will be finished before the enter requests for the new version are processed.

The protocol right now is very simple, a master instance simply tracks enter requests until the height is reached and then unlocks all users. While there are other algorithms which use optimized tree structures or broadcast to reduce the latency, we haven’t seen the need to implement a more complex algorithm.

Introducing Collage

6. July 2012

Collage evolved from the Equalizer network library. Now it’s used by a few other projects as well, and I’ve been mentioning it quite a few times on this blog already.

Looking back over the last seven years of Equalizer, Collage has received by far the largest investment in manpower compared to all the other components. It seems innocent enough, but trust me, getting a distributed network library right and bug free is no small task. On the one hand, the ‘fun’ implementation of the Windows IP stack (WSASYSCALLFAILURE and stack corruptions) took a lot of debugging to get going, and on the other hand advanced features such as InfiniBand support (thanks Dardo!) and fast, reliable multicast are no small task to implement.

What’s wrong with boost::asio?

Nothing. It provides about the same functionality as co::Connection and co::ConnectionSet. We use it as the UDP backend for the RSP multicast implementation. It wasn’t around when I started eq::net, which became Collage. We’ld love to replace co::Connection and co::ConnectionSet with it, but the effort of porting the RDMA and RSP connections to asio has prevented this so far. Ultimately Collage tries to provide higher level abstractions.

What’s wrong with 0MQ?

Again: Nothing. It provides higher level abstractions then asio. It’s less likely that we’ll use it as the backend for Collage, since some of the design decisions are somewhat different from what Collage is doing.

So, what’s next?

Collage, similar to Lunchbox, aims to provide high-level abstractions. Similarly to the introducing Lunchbox series, I’ll present them over the next few weeks. In the same timeframe, we are planning to separate the Equalizer and Collage projects as well as to define and document the ’1.0′ Collage API.

For now, you can find a technical overview presentation on the Collage website. Enjoy!

Programming and User Guide for Equalizer 1.4

29. June 2012

Equalizer Programming and User Guide

Equalizer Programming and User Guide


I’ve just uploaded the review version of the Programming and User Guide for the upcoming 1.4 release of Equalizer, and to a certain extent, Collage.

This one packs 111 pages of content (118 total) and 63 figures. In a couple of weeks I’ll create the final hardcopy version on Amazon/CreateSpace.

What’s New?

This edition has, among the customary full review pass, a lot of new content. Starting with a full new chapter on Sequel and the associated polygonal rendering example, continuing with new section for application-specific scaling factors in immersive environments, region of interest for compositing and load-balancing and zeroconf discovery in Collage, finally finishing with a substantial rewrite of the section on distributed objects in Collage.

What?

The book is structured in two parts: The User Guide, laying the foundation on parallel rendering and scalability algorithms, and then explaining the configuration of visualization systems for Equalizer applications. The appendix contains a full reference on the file format.

The second part, the Programming Guide, gradually introduces programming parallel rendering applications. Starting with the basics in eqHello, the complexity is gradually increased with a chapter on Sequel and Equalizer using the respective example application. After this, an advanced features section focuses on introducing and demonstrating on specific features in isolation. It finishes of with a chapter on the Collage network library.

Why?

The Programming and User Guide is the ‘OpenGL red book’ of Equalizer. It consolidates all the documentation available in various places (Equalizer website, mailing list, github feature issues, my head) into a single document. Apart from gathering this information, through the format emerges a bigger picture, putting design decisions in context.

1.4 beta release of the Eyescale open source packages

20. June 2012

We are pleased to announce the 1.4 beta release of the Eyescale open source packages. This release is a preview for testing the upcoming 1.4 stable release. It is the first modular release, and contains the following libraries and new features:

  • Equalizer: parallel rendering framework
    • Various scalable rendering performance features: asynchronous readbacks, region of interest and thread affinity.
  • Collage: C++ library for building heterogenous, distributed applications
    • Zeroconf support and node discovery
    • Blocking object commits
    • Increased InfiniBand RDMA performance
  • GPU-SD: discovery and announcement of GPUs using zeroconf
    • VirtualGL detection
    • Hostname command line parameter for gpu_sd daemon
  • Lunchbox: C++ library for multi-threaded programming
    • Servus, C++ interface to announce, discover and iterate over key-value pairs stored in a zeroconf service description
    • LFVector, a thread-safe, lock-free vector
  • Buildyard: A CMake-based superbuilder to download, configure and build the packages and dependencies for this release
    • Generates Unix Makefiles and solution files for Visual Studio 2008/10
    • Simple CMake project configuration scripts
    • Support for local overrides and user forks
    • Extensible with custom in-house or open source projects
  • http://eyescale.github.com: A website for API documentation of all
    the aforementioned packages

Please test this release extensively and report any bugs on the respective project page at https://github.com/Eyescale. The release notes are part of the API documentation at http://eyescale.github.com.

We would like to thank all contributors who made this release possible.

Buildyard + doxygen + github = eyescale.github.com

15. June 2012

Sometimes pieces just fall into place and you know you’re on the right track. While preparing the 1.4 beta release of our Eyescale software stack (Equalizer and friends), I needed to put the API documentation of all these projects on a web server. In the past, with Equalizer as a single project, I just had doxygen dump it somewhere and then copied the stuff at release time to equalizergraphics. With five or more projects, that’s not really an option anymore.

Meet eyescale.github.com: Our new home for all doxygen-generated API documentation. For us, the process is almost fully automated:

  • github provides a git repository for all the web pages, and automatically serves them at eyescale.github.com
  • Buildyard has a configuration which clones this git repository before all other projects.
  • A per-project CMake rule installs the project, runs doxygen on the installed headers, and copies the result to the git repository into project-version
  • CMake magic in the git repository rebuilds the index page and adds all new files to the repository
  • A manual git commit; git push uploads the new pages to the git repository, and github automatically updates the website.

This took about one day to setup, and now it takes almost no time to update API documentation. It has the added benefit that you can easily get all the reference documentation by simply cloning the git repository.

Buildyard – C++ source project management

1. June 2012

The Problem

The Equalizer source code always was modularized, but did build everything into a single shared library for convenience. Lately new projects, e.g., dash/codash, required functionality from what was called eq::base. This lead to Lunchbox, which you should know by now.

Managing the development of multiple, source dependent projects is a pain. You’ve got to download them, configure, build and install them in the right order. There are solutions for this in the Java world, but the ones I found for C/C++ were either in limbo (ryppl) or are more for source-based distribution, but not that easy for developers (0install).

Our Solution

After some tinkering we came up with Buildyard, a CMake-based meta build system. It builds on top of the ExternalProject CMake module, which is good but requires quite some customization when used. We’ve simplified this further, and adding a new CMake-based project is a couple of lines in a configuration file, e.g.:

set(EQUALIZER_VERSION 1.3.1)                                                     
set(EQUALIZER_DEPENDS gpu-sd Boost hwloc vmmlib Lunchbox GLStats)                
set(EQUALIZER_ROOT_VAR EQ_ROOT)                                                  
set(EQUALIZER_REPO_URL https://github.com/Eyescale/Equalizer.git)                
set(EQUALIZER_REPO_TAG master)                                                   

Creating this simple configuration files allows you to build a project such as Equalizer, and all it’s dependencies, much easier. You simply clone Buildyard and use make Equalizer in the cloned directory. This will first configure Buildyard to resolve the dependencies, download the ones not installed yet, and then configure/build/install them in the correct order into a local installation directory. This even works with parallel builds.

The development process is largely unchanged as well. Simple go to src/project, code and compile away. Buildyard will inject a Makefile into each project source which sets up the proper targets for building. When compiling in a source directory, other project dependencies are not considered by default to get speedy compiles.

The whole thing is easily extendable. Internally we’ve got a config.bbp repository for the closed-source project configurations, which build on to of the open source ones pre-configured with Buildyard. Developers clone that into the Buildyard directory, where it will be picked up on the next CMake run.

This post just scratches the surface, have a look at the Readme for more details and post questions below. While it’s not as sophisticated as ryppl, it works and we use it daily already in quite a number of projects. It also facilitates creating new projects a lot, such as dash, codash, Lunchbox and GLStats.

EGPGV 2012

15. May 2012

If you were wondering what’s up with last week’s ‘Introducing Lunchbox’ post: There wasn’t one since I’ve been to the Eurographics Symposium on┬áParallel Graphics and Visualization to present our paper “Parallel Rendering on Hybrid Multi-GPU Clusters”. This week I’m attending Eurographics, but I’ll try to post the fourth article in the Lunchbox series by Friday.

Our paper presented a collection and evaluation of optimizations for medium-sized GPU clusters which use Multi-GPU NUMA nodes. This type of architecture is quite important, since it provides a cost-effective configuration for parallel rendering, since the host and network infrastructure cost is amortized over multiple GPUs. During this paper we found a few surprising insights (<cough>glFinish</cough>) on what optimizations are actually important.

Enough talk: The most important parts are summarized in our presention. Enjoy!


Follow

Get every new post delivered to your Inbox.

Join 40 other followers