<< Work in progress >>
<< Images to come >>
A couple of weeks ago, I posted a entry about me pondering upon writing
a series of articles on GPU, and topics related to GPUs such as
graphics. This first article will be a gentle introduction to the world
of graphics, trying to give you, the reader, a bird’s overview of the
entire pipeline. But first some general rules about this series of
articles. Unlike others, I won’t go into the trap of saying that it will
not be a lot of math required to understand the GPU. The GPU and 3D
world is based upon mathematical principles, and thus a lot of the
behaviour is best described using mathematics. I believe I shall manage
to steer clear of mathematics in this introduction, but if you seriously
want to learn how the GPU works, I strongly suggest brushing up on your
linear algebra.
BREAK
Don’t panic!
Most modern computers nowadays have a special processor for dealing with
graphics, being either 2D or 3D graphics. The reason why is two-fold,
first it allows the CPU to concentrate on more the more important work
at hand, and secondly it allows a more specialized processor than the
generalized CPU. While today’s CPUs operates at core frequencies around
~4Ghz, GPUs can still beat them at certain tasks operating on a mere
1.4Ghz. This is mainly due to being a highly specialized device, and it
having a lot of simple cores. Well, simple compared to the CPU core.
While this specialization is great for certain domains, e.g. graphics,
it decreases the performance in other fields. To begin understand why, a
fundamental understanding of the graphics pipeline is important.
When a programmer programs a 3D application, he does so by creating a
geometrical object, gives it a place in the world and then applying
texture, before it appears on the monitor. Simplified this gives us 4
steps. Create geometrical object => place it => texture => monitor, and
which is reflected in both the OpenGL and DirectX pipelines. In a more
technical terminology this is called Vertexes => Vertex Shader =>
Fragment Shader => Monitor. This simplified model has left out a
fair share of important details between the different steps, but works
for now.
In order to describe a shape to appear in the scene, the developer sends
the GPU a series of 4-component vectors containing its position, X, Y, Z
and a special H component describing if it is a point. Being a
4-component vector allows us to do more transformations, but this is a
topic to be further discussed in the article on vertex shaders. This
stream of vertexes are so sent to the vertex shader, where they are
multiplied with a 4×4 matrix to give them a position in the view. When
the vertexes are transformed, they are assembled into predetermined
shapes as specified by the programmer. OpenGL and DirectX gives the
programmer 8 different shapes, whereas the rectangle is the most used
one. By specifying a lot of rectangles, it is possible to describe very
complex figures such as planes or overly dimensioned heroines.
< Reread >
When the basic geometric shapes are assembled, they’re sent to a rasterizer.
The rasterizer’s job is to create fragments. It does so by looking at the shape
described by the vertexes, and create a set of fragments/points that might
appear on the screen. Now, I know that this might be confusing if it’s the
first time you read about graphics, but I’ll try to explain the difference
between a fragment and a vertex. Think of the vertexes as a way describing the
corners in a triangle, while fragments are all the possible points inside the
triangle. The points necessary to create the physical manifestation of the
triangle, so to speak. In the figure below you see three vectors describing the
triangle, while fragments actually makes the body of the triangle.
When the rasterizer is done, it sends its fragments to the fragment
shader. The fragment shader, working on the physical manifestation (
remember? ), applies texture to the fragments and other special effects
such as light. When the fragment shader is done, the fragment will be
checked if it overlaps a previous fragment. No point in further
processing a fragment if it is behind an already drawn fragment. (
Usually this step has also been done earlier to reduce the work load. )
If it passes the check, it will finally qualify for a position on the
screen.
Being a quick and dirty introduction to the pipeline, several steps has
been omitted in order to, I believe, make it a better birds view of the
pipeline.
