Vinicius wrote:
[ munch ]
But I like the idea, specially because programmable vertex/pixel
shaders aren't important only to games, but CAD(in a generic sense)
as well. And let's not forget uni-verse ^_^
Agreed. Programmable GPUs are standard on every modern game console
and desktop platform except for Linux, and anyone doing R & D in
computer graphics, 2D or 3D, is relying on programmable GPUs.
Timothy Miller wrote:
I wonder if there isn't some way that we can be 'wasteful' in order to
get performance. How about adding gobs of memory to the card and
somehow employing that? Maybe our shader microcode would be horribly
space-inefficient in exchange for being reasonably fast?
Compared to the megabytes of textures being downloaded to the card
(not just for 3D games, the entire contents of the desktop in a
modern window manager) any space inefficiencies in the instruction
coding won't matter.
I think the 3D graphics cards have fast memory with wide buses, but
also special addressing logic/caching designed to match how texture
mapping shaders use it.
So, as I understand it, there's a geometry processor. The geometry
processor takes objects in world coordinates, transforms them into
screen coordinates, and shades vertexes. The vertex shader and the
fragment shader could use similar languages.
There's actually a LOT of geometry/fragment processors. "Computer
graphics is embarassingly parallel" to quote Dave Kirk of nVidia.
The latest ATI/nVidia GPUs have 48 or so mini SIMD ALUs, which can
be allocated to either vertex or fragment processing. There used
to be differences between vertex and fragment units, but now
fragment shaders have switched to full floating point arithmetic
and vertex shaders have access to texture maps, so they are almost
identical.
Very deep pipelining is becoming less effective than before, as
version 2 shaders introduced branch instructions and hence the
problem of bubbles and stalls. But having lots of parallel units
still works.
--
Hugh Fisher
DCS, ANU
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)