Balder: A Silverlight 3 Managed 3D Engine Optimized for Multicore

Silverlight 3 doesn't offer native support for loading and rendering 3D models. However, Balder, an open source project, offers a very complete managed 3D engine for Silverlight 3. It achieved the necessary frame rate taking advantage of Silverlight's threading capabilities.

This time, I'm going to share a nice experience about great results achieved parallelizing an existing algorithm. I had the opportunity to be a witness of the evolution of a 3D engine, Balder.

In a previous post, I had already talked about designing Rich Internet Applications with parallelism in mind. Balder's creator, Einar Ingebrigtsen, implemented this idea in its managed 3D engine for Silverlight 3.

I've been working with Balder in many projects in the last year and I had the possibility to talk to Einar and Petri Wilhelmsen (two gaming gurus) about many potential performance improvements. Balder doesn't use the GPU (Graphics Processing Unit) to render 3D models. It uses a software rendering process. Silverlight 3 has many restrictions and you cannot access DirectX or OpenGL from a Silverlight application. Therefore, an efficient software rendering process was the only opportunity to bring 3D models to life in a Silverlight viewport.

There are other open source 3D engines offering some software rendering capabilities to Silverlight. However, one of Balder's key features is its optimization to take advantage of multiple logical cores (hardware threads) in the software rendering process. This way, it is capable of offering a very interesting frame rate when running on microprocessors with two or more logical cores (hardware threads). Silverlight 3 doesn't offer the new task-based programming included in .NET 4. You have to work with the classic .NET 3.5 Threading model in order to take advantage of multiple cores.

Balder's software rendering process had a reasonable performance. However, it was not enough to reach 60 frames per seconds (FPS) with dozens of 3D models being rendered in real-time. The software rendering process was using a single-threaded model, old-fashioned non-scalable sequential code. Rewriting a complete software rendering algorithm to take full advantage of multiple cores is indeed a very complex task.

However, there was a very easy to detect hotspot. A very easy to identify block of sequential code that could be broken down into many concurrent blocks of code. Balder's team worked to optimize this loop using multiple threads. They used wait handles to coordinate the start and the end of many concurrent loops. Of course, this process required a new design. It wasn't just a copy and paste. It wasn't a simple code refactoring. The new design had to consider concurrency. Nevertheless, as the focus was in just one block of code, it was easier to achieve faster results than rewriting the complete engine.

The performance improvements were really important. The rendering process was really faster when more than two logical cores were available. Balder became a really serious 3D engine with a high performance software rendering process. It has a great advantage over other 3D engines for Silverlight, because it uses many logical cores to improve its performance.

But wait, what about compatibility? There were many incompatibility problems with the new multithreaded version. A classic multithreading problem. Some code in the engine was supposed to run on the main UI thread (the only thread capable of making changes to the UI controls). In the optimization process, some of this code wasn't running on the main UI thread anymore. Therefore, some applications didn't work as expected. Luckily, the problem was solved in a newer version. This is a very interesting situation. When you optimize an engine to take advantage of multiple cores using concurrent code, you have to keep compatibility with previous versions. There is a lot of code prepared to use the services offered by this engine. Einar solved the problem in just a few hours.

Performance improvements in engines shouldn't destroy backward compatibility.

The parallel code used in Balder isn't perfect. There are many other possibilities to offer more scalability and to improve its performance. However, it's a good example of how to translate multicore power into application performance. I'm sure Balder's team is going to improve the engine in future versions and they'll be able to take even more advantage of multicore microprocessors.

What are you waiting for? It's time to go parallel. If you find a RIA running too slow, remember that you can take advantage of multiple cores in many programming languages used for developing RIAs.

You can read more details about Balder's optimizations in this post written by Einar Ingebrigtsen: "Balder Silverlight 3 optimization - round 1"

You can compare the performance and the code for this 3D engine downloading the different versions from its Codeplex website