(note: this is slide 5 of the nulstein plog)

In an Agatha Christie novel, this slide would really go at the end of the talk, everything would finally get revealed only in the end, leaving the reader to play detective, picking up clues as the story unfolds… But that’s not what I want, this slide goes here, like in a good old Columbo episode: you get to see what happened straight away, and we’ll go over everything again to understand the details and make everything right again.

Having found the functional decomposition too complex for my taste, I went back a few steps, trying to split the work up along a different edge. At the time, I was looking at Google’s map-reduce and also at the Larrabee rendererer, and one thing really struck me then: what Abrash describes can be seen as a system that maps triangles to tiles and then reduces these to bitmaps… And to generalize this: it is okay to break a process in sequential steps, as long as each step exhibits good parallelism.

Isn’t that great: sequential is okay, after all!

This lead me to break the update in two parts: a read-only part and a write-only part. When all that gets done is reading, there is no need for locks, everybody can do it at once. When all that gets done is changing own state, again there is no contention possible and no arbitration is required. Of course, there are a few more nuts and bolts required to make this work, but here you have it: split that update in two phases, and everything can get updated in parallel much more easily.

Breaking the draw phase down is quite easy too, collect information about what everything wants to draw, sort that and do the actual render in multiple deferred render-contexts (as provided by DirectX 11). Here, it can almost be seen as straight map-reduce: a set of objects is processed to generate set of intermediate key/value pairs, which gets reduced into a set of command lists, ready to render.

The unexpected part for me, when carrying out development, was that I would still have one thread just talking to DX and very busy doing that. That’s the part I was trying to kill and, as it turned out, it did survive and stop being a problem.

There are five slides before we really dive into the details of how this works, which should turn into a couple of weeks worth of blogging, so I’d like to invite everyone who is interested to start playing in their mind with the idea of two-stage update (all read and, later, all write). Look for things that don’t look like they should work, look for ways to address those problems, try and see what in your game would stop working if it had to be written like that, and try to think if there would be any way to fix it. That’s the great thing about making this talk a plog: you get to really think about what I present while I’m presenting it. The unfortunate thing is that our comments system seems to be down at the moment and we can’t interact properly. So, if anybody wants to feedback, feel free, you can twitter @jmuffat or email jerome dot muffat dash meridol at intel dot com.

Next time, demo! : to be continued
Spoiler (slides+source code): here

. Read the rest at Intel.com.