seeding the pot for 2.0 features [small vectors]

[Mikola Lysenko]

Bill Baxter wrote:
> "Most CPUs today have *some* kind of SSE/Altivec type thing"
> 
> That may be, but I've heard that at least SSE is really not that suited 
> to many calculations -- especially ones in graphics.  Something like you 
> have to pack your data so that all the x components are together, and 
> all y components together, and all z components together.  Rather than 
> the way everyone normally stores these things as xyz, xyz.  Maybe 
> Altivec, SSE2 and SSE3 fix that though.  At any rate I think maybe 
> Intel's finally getting tired of being laughed at for their graphics 
> performance so things are probably changing.
> 
> 

I have never heard of any SIMD architecture where vectors works that 
way.  On SSE, Altivec or MMX the components for the vectors are always 
stored in contiguous memory.

In terms of graphics, this is pretty much optimal.  Most manipulations 
on vectors like rotations, normalization, cross product etc. require 
access to all components simultaneously.  I honestly don't know why you 
would want to split each of them into separate buffers...

Surely it is simpler to do something like this:

x y z w x y z w x y z w ...

vs.

x x x x ... y y y y ... z z z z ... w w w ...


> "Library vs Core"
> 
> I think there's really not much that you can ask from the core.  A small 
> vector of 4 numbers can represent any number of things.  So I think your 
> best hope for the core is to support some very basic operations on small 
> vectors -- like component-wise +,-,*,/, and dot product -- to optimize 
> those kind of expressions as best as possible, and leave everything else 
> to libraries.  I guess that's pretty much how it works with HW shader 
> languages.  Except they add swizzles to the set of primitive ops.
> 
> 

Yes, I think this is probably the best course of action.  Because of the 
nature of vectors, and the fact that they require such careful compiler 
integration, they must be placed in the core language.  On the other 
hand, most products like dot, cross, perp or outer should be in a 
library.  The reason for this is that there are simply too many types of 
products and operators for a language to reasonably support them all. 
At any rate, once you have the basics you can quickly build up the 
others.  Here is an example of a cross product:

float3 cross(float3 a, float3 b)
{
	return a.yzx * b.zxy - a.zxy * b.yzx;
}

Implementing most products and vector operations is easy once you have a 
simple component-wise vector library.


> "Getting it in the standard library"
> 
> I agree, though, that lo-D math is common enough that it should be 
> included in a standard library.  I wonder if the Tango developers would 
> be willing to include a vector math class...or if they already have one 
> in there.
> 

It may eventually get in.  However, it would be far more optimal if the 
language simply supported them in the core spec.


-Mik