Timothy Normand Miller wrote:
Besides the obvious scalar ALU instructions, there are other
instructions that take bandwidth that are also not vector: flow
control, loads and stores
There's lots of those. No?
No. A vertex shader has to multiply the vertex by the current matrix
which is four 4-way multiplies and four 4-way adds. No branching.
Standard OpenGL/Direct3D fixed pipeline lighting has one loop, over
the available light sources, say two scalar instructions. Each time
through the loop there's the surface normal multiply by (3x3) matrix
and normalise, thirteen 3-way multiplies/adds and one scalar division.
Lighting equation is eight (maybe more, depending on LIT) 4-way
multiplies/adds and one scalar test & branch.
Loads and stores are mostly of matrices (eg skinning), or materials
and colors which are one or more 3/4-way RGB/RGBA vectors.
Loads from texture maps are also vector ops, either RGB/RGBA vectors
or surface normals or other 3/4-way floating point vectors.
Also, if memory load instruction latency dominates, then none of this
matters. Many shader programs will spend most of their time waiting
on memory, making vector optimizations moot.
If memory load is important, isn't SIMD faster than fetching and
executing four scalar instructions in succession?
I can see vertex shader programs being DP heavy. But there will be
far fewer vertexes than fragments. How DP-heavy are fragment shader
programs, generally?
Vertex processing is more important for CAD type workloads (lots of
wireframes). For all types of 3D, as geometry is tessellated into
smaller polys for more detail, the number of vertices increases relative
to fragments.
In classic 3D, fragment shaders do texture loads and color multiplies,
all 3/4-way vector ops. Modern fragment shaders implement full lighting
calculations (see above), bump or displacement mapping (vector math),
fogging effects (vector math). Yes they do test and branch as well,
but like most aspects of 3D they are heavy on the vector/matrix maths.
--
Hugh Fisher
CECS, 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)
