> I am pretty new to OpenGL. After trying out a few examples, i
> downloaded the Mesa source code and looked at the 3D driver (ATI :
> r300) to see what operations are typically accelerated. I guess that
> this
> is not a simple task that can be done quickly with so many
> indirections in the code :-) Some are obvious where ctx->Driver
> functions are initialized by the driver. Then there are the software
> fallback modules vbo etc. also that initializes the Driver functions.
> For example, i was trying to see if the Vertex operations like
> glVertex2f() are accelerated. I was unable to find it out. Is there a
> good do***ent that describes how the 3D driver acceleration works ? I
> searched but could not find a do***ent describing this. Any help on
> this would be appreciated.
First you have to understand what the glVertex2f() implies; it implies
that
the data is read from the parameters passed to the function. Usually this
is
a bad sign; the graphics processors often can only use local memory
(memory
close to the graphics processor, on-chip, or at least on the same discrete
graphics board).
There are many different architectures, some use so-called UMA where the
system memory is shared between the graphics processor and application
processor. This is very inefficient as both contest for access to the same
memory. More bandwidth-friendly approach is to have own dedicated memory
for
the graphics processor, this can and is done on both discrete graphics
boards and integrated graphics (in various shapes and forms), however,
this
approach requires the data from the so-called system memory (application
processor spesific memory) to be copied to the memory that the graphics
processor can access. This on the other hand requires extra overhead.
Regardless of the various tradeoffs between different designs, there is a
rule-of-thumb to follow: if possible, store the data in graphics processor
specific storage location. In other words this means use Vertex Buffer
Objects, or VBO's in short. This eliminates all kinds of nasty things the
graphics driver has to do and there by improve the performance. Display
Lists are also capable of doing this sort of optimization.
The glVertex2f() itself is not "accelerated", it just way to input vertex
data. It just defines a new vertex. The draw call is where the action
takes
place: the driver uses all the collected data to draw primitive(s). I use
the word "uses", because that doesn't necessarily mean that anything is
happening at that time, it could just update the command buffer, if the
driver has one, or similar mechanism.
A good driver is asynchronous; the hardware is doing it's tasks while
freeing the CPU to do it's tasks.. this means the internal buffers and
data
are more dynamical than static and requires some creativity from the
driver
authors, but not that much, but the point is that unless you are aware of
such things taking place, the driver code might be a slightly difficult to
follow. But when you do, it's all peachy.
The key thing is that glVertex2f and similar calls shouldn't invoke any
register writes or other nasty business to take place, just store the data
and send it in one big packet to the GPU to think about. That's less
overhead than invoking some transfer mechanism for each vertex
(fetch-convert unit, dma, register writes, what ever.. architecture and
platform specific details which are too numerous to enumerate..)
....
|
