[sldev] Vectorization (OpenJPEG)

[Dzonatas]

Callum Lerwick wrote:
> There's a reason I've been trying to go for autovectorization rather
> than explicit vectorization. :)
>
> Supposedly icc has some pretty wicked autovectorization capability. No
> idea about Microsoft.
>
> I'll have to play with this patch. Does it really need to be fp?
> OpenJPEG seems to lean more towards integer. With modern processors, I
> wonder which is actually faster... :)
>   
Answer: whatever can provide the most throughput.

On that note, throughput issues will be the downfall of the GPU as we 
know it. We have had GPU's and CPU's fight for the same memory, one has 
got to give. I put my bets on that the CPU isn't going to give up 
control. =)

Difference between FP and integer math is that integer math requires 
more bandwidth. When you multiply or divide in integer math, you need a 
64 bit data type to store the intermediate value for two 32 bit values. 
DDR memory provide 128 bit data paths, so the most you can cram together 
in one cycle is 2 math operations. Then, you need to follow up those 
operations to convert the 64 bit data back to 32 bit. That all use to be 
faster than FP.

Today's vectorized FP allows one to store 4-32bit data FP types, which 
fills that 128 bit data path. Then in 1 math operation that can happen 
in less than a cycle all four FP units perform.

If you customize the vectorization correctly, you load up all the vector 
registers, than issues the sequence of math operations. That sequence 
may all happen within one cycle. At that point, the vector operations 
actually become matrix operations.

While auto-vectorization is being done with modern compiler technology, 
that is some cool stuff. The compiler is only limited to inner loops for 
auto-vectorization. However, auto-matricesization is the bleeding edge.

("auto-matrixization" for those who can't spell)

With that last patch I posted, why can't the compiler auto-vectorize the 
vector I provided? =)