

How Video Cards Work - macco
http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork

======
Jabbles
An interesting aside:

[http://en.wikipedia.org/wiki/Single-letter_second-
level_doma...](http://en.wikipedia.org/wiki/Single-letter_second-level_domain)

------
acabal
Whenever I read about the guts of video hardware or 3-d game programming it
always amazes me that this kind of stuff even exists. It's _so_ complex!

~~~
sparky
3D graphics is also my favorite success story for programming abstractions.
This code:

    
    
      glColor3f(1.0, 0.0, 0.0);
      glBegin(GL_TRIANGLES);
        glVertex3f (-1.0, -1.0, 0.0);
        glVertex3f (1.0, -1.0, 0.0);
        glVertex3f (0.0, 1.0, 0.0);
      glEnd();
    

Has been able to draw a red triangle for almost 20 years, on nearly every GPU
released from a few dozen vendors. It transparently gets faster without you
having to do much.

As a result of everyone having to writing code like the above, as opposed to
assembly code specific to each GPU, the GPU vendors have been able to change
their architecture tremendously over the years to adapt to changing process
technology tradeoffs and add new features.

They've been able to do this in part because 3D graphics is a well-enough-
defined domain and can be reasonably API-ified, but I could easily see things
having gone a different way; people would be arguing about whether the ARM of
GPUs would conquer the x86 of GPUs, given the massive install base of the
incumbent. Instead, to some extent, anyone who can write an OpenGL compiler
can play.

~~~
emarcotte
On the other hand, that same path has shown to be quite problematic, right?
Lets say you have 10000 verticies, that's 10000 function calls to make. Sure,
you could precompile a display list, or use some other work around, but we've
finally come to the point where it is not fast enough anymore. Welcome to
opengl 4, i'll miss the easy to understand glBegin blocks.

~~~
sparky
You're right that giving the OpenGL runtime information piecemeal (one vertex
at a time, repeated every frame) is no longer acceptable for many apps in
terms of performance, but I'd argue that that's not a strike against the
abstraction layer per se. We've gone to a world where the code I posted was
the only way to go, to a world where that works but is slow, and people who
care about performance use display lists and vertex buffers and shading
languages. However, most graphics code still feels like it's about graphics --
vertices, triangles, groups of triangles that share properties, lighting,
shading -- and not about the registers you need to poke to set up the
rasterizer on such-and-such chip, or how to optimally pipeline shaders to get
the best hardware utilization.

The abstractions we have now are more complex than ever, but they are still,
for the most part, in the problem domain -- it is possible to do weird things
to your code for performance tuning, but it's just not possible to go as far
with it as you can for a machine whose behavior is specified and guaranteed at
a very low level.

