Graphics Reference
In-Depth Information
Due to the huge amount of variation among implementations, it would be impractical
to provide detailed information here. We invite the reader to explore this fascinating topic
in more detail, with a good starting point available in (Fatahalian). However, we can still
provide a general idea of how a GPU is organized, so that discussions later in the topic will
have a context to build upon. The GPU has evolved into a massively parallel processor,
housing hundreds of individual ALU processing cores. These processors can run custom
programs, and they can access a large bank of memory, which allows for high-bandwidth
data transfers. Each GPU uses some form of a memory cache system to reduce the effec-
tive latency of memory requests, although the cache system is vendor specific and its low-
level design is generally not disclosed. In the past, it has been necessary to understand the
individual architectural details of a particular target GPU in order to attain the maximum
available performance level. This trend will likely continue for some time into the future,
due to the fact that GPUs are still evolving at a very rapid pace.
3.2 Pipeline Execution
The fixed function stages, together with the programmable stages, combine to provide an
interesting and diverse pipeline with which we can render images. The process of execut-
ing the pipeline consists of configuring all of the pipeline stage states, binding input and
output resources to the pipeline, and then calling one of the Draw methods to begin execu-
tion. All of these tasks are performed through the methods of the ID3DllDeviceContext
interface. The number of pipeline executions performed to generate a rendered frame de-
pends on the application and the current scene, but we can assume that at least one pipeline
execution is performed for each frame.
Once the pipeline has been invoked with one of these draw methods, data is read into
the first stage of the pipeline from the input memory resources. The amount of data read
from the input resources depends on the type and parameters of the draw call used to invoke
the pipeline. Each piece of data is processed and passed on to the next stage until it reaches
the end of the pipeline, where it will be written to an output memory resource. Once all of
the data from these draw calls have been processed, the resulting output resource (typically
a 2D render target) can be presented to an output window or saved to a file.
Throughout this chapter, we will see how to configure each stage of the pipeline, as
well as understand the differences between each of the draw methods. There are seven dif-
ferent draw methods that can be used to invoke the rendering pipeline. They are listed here
for easy reference, and to demonstrate that a fairly wide variety of methods is available for
invoking the rendering pipeline.
Search WWH ::




Custom Search