[subheading]Render Views[/subheading]
The basic unit of work is the render view in Hieroglyph 3. This is basically an object that performs a series of rendering and/or GPU related tasks. The general concept is to group a series of related rendering operations together so that they can be handled as one object. Grouping of work in this manner provides for a fairly easy transition into using the multithreaded rendering capabilities of D3D11 too, so there are organizational as well as performance benefits to using this arrangement.
Choosing the size and amount of operations to include in each view is really dependent on the particular scene being rendered and the algorithms being used to produce the final output rendering. In general, I follow a logical grouping of the operations (so that they can be reused in other applications) and try to size each batch of work to match one another if possible. For example, in the AmbientOcclusion sample I use one view to generate the Depth/Normal buffer of a scene, one view to produce a smoothed occlusion buffer, and one view to do the final scene based perspective rendering. Each of these do a fairly large chunk of work, although not exact same...
I am in the process now of refactoring the DeferredRendering and LightPrePass samples so that they can utilize the full MT support in the engine. Currently, the work done for the samples is broken into multiple render views, but they are processed serially. The coming days will bring some new view types to be added in for the HUD rendering, and then the material system will be used directly to allow all of the views to be processed automatically instead of being directly managed by the application. This should move the rendering logic into the views, which is where it is intended to be.
[subheading]Advancing Render Views[/subheading]
After working with the render view objects for a while now (its been a main concept for several years in my engine) I am starting to realize that they can be used for more unconventional GPU style operations too. More or less, any operation that needs to interact with the GPU can be packaged into a render view - which allows it to be inserted into my material system with very little work on the part of the application. This means that any actions, like loading resources with data, can be done with deferred contexts in parallel to any other threads that are currently working.
This can of course be used for traditional types of things in games that require parallel loading of data like terrain paging or whatever, but could also be utilized for acquiring some newer style data. It isn't quite ready for prime time yet, but I'll add a small teaser to show an example of the types of data acquisition that can be performed:
Going forward, I will be really trying to build up the render view catalog, and try to squeeze out as much multi-threading goodness from the library as I can...
[subheading]In Other News[/subheading]
In separate news, I found out yesterday that I was re-awarded the MVP status for DirectX/XNA!!! This is the third year running, so I hope I can continue to contribute at the same level to the Direct3D community. Especially with Windows 8 coming, I think there is going to be lots and lots of new stuff to learn, so I am really looking forward to the challenge!
