In the extreme case, feeding a high performance graphics pipe looks a lot
like bcopy (doesn't everything). You have a bunch of data which you need
to read from memory into the CPU and then blast out to the graphics card.
The number of intermediate buffers in between directly affects your
performance.
Assume you want to achieve 10 Million lit, texture-mapped vertices per
second. How much memory bandwidth do you need? Well, you have to transfer
the vertex coordinates (3x4 =12 bytes), normal (3x4=12 bytes), and texture
coordinates (2x4=8 bytes), for a total of 32 bytes per vertex.
If you can read that data out of memory and write it directly to the
graphics hardware, this "only" requires 640 MB/s of CPU bandwidth and 320
MB/s of
memory bandwidth. Write it to a DMA buffer instead, and now you are at 640
MB/s of CPU bandwidth and 960 MB/s of memory bandwidth. Add a copy from
the server's input queue to the DMA buffer and you are at ~1.3 GB/s of CPU
bandwidth and 1.6 GB/s of memory bandwidth.
If you get the driver model wrong, it is quite easy for certain levels of
performance to drift from "hard" to "impossible". Bulking commands into
buffers and letting the server do all the talking to gfx is simple from an
implementors point of view, but it reduces the absolute level of immediate
mode graphics performance which you can achieve with a given CPU and memory
architecture and increases the overhead required to get there.
I presume this is part of what GGI is trying to get around? I haven't
spent much time in the code yet.
nate
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu