Graphics Reference
In-Depth Information
For example, the generation of a shadow map
would be one view of a scene. The generation of
an environment map would be another, and the
regular perspective rendering of a scene would
also be considered a view. If you consider the
normal single-threaded series of rendering com-
mands to be one continuous list, then a general
rule of thumb for splitting the list into views
would be to break them whenever the render tar-
get is changed or cleared (or in the case of com-
putation pipeline execution, when the UAVs are
changed). This splitting is shown in Figure 7.8.
With this partitioning, we would break
up the rendering workload into these discrete
chunks and hand them off to the worker threads
to be processed into command lists. Each scene
view would proceed with the rendering code it
normally uses, except that it would be working
with a deferred context, instead of an immediate
context. Implementing this segmentation of the
work may be somewhat difficult, depending on
how a rendering pass is currently implemented
in a rendering framework. One topic that must be
considered is that of data synchronization. As an
example, let's assume that an application uses a
scene graph to contain its scene elements. If the
graph is traversed once for each of our rendering
views, and these transversals are carried out on
different threads, we must ensure that the state
of the scene graph itself is not modified in any
way by any of the threads—otherwise, we risk
(and almost certainly induce) data corruption be-
tween rendering threads. We also would like to
avoid using manual synchronization code, since
it will detract from any performance benefit we
get from multithreading. In general, all updating
for a given frame must be done prior to the ren-
dering pass, or else any data modification must be
very carefully planned out!
Figure 7.8. High-level rendering operations
can be used to split a rendering sequence
into "views."
Search WWH ::




Custom Search