[macstl-dev] Re: [Fwd: Multiplication?]

[Glen Low]

Dear All,

On 27/02/2005, at 6:45 PM, Asger Ottar Alstrup wrote:

> Dear Macstl developers,
>
> AGG is an advanced open source graphical rendering engine which 
> provides sub-pixel anti-aliasing rivaling GDI+ and what else is out 
> there.  See http://www.antigrain.com/.
>
> It is a natural fit for macstl. The author of AGG, Maxim Shemanarev, 
> tried macstl, but could not get a simple multiplication to work.
>
> Any ideas?
>
> I'm not subscribed to this mailing-list, but I've cc'ed the AGG 
> mailing list. Please cc that in any replies.
>
> Thanks,
> Asger Ottar Alstrup
>
>
> Maxim Shemanarev wrote:
>>> Check out the macstl project:
>>>
>>> http://www.pixelglow.com/macstl/
>>>
>>> It contains a portable library intended for this kind of thing.
>> Thanks!
>> I gave it a try, but I failed to multiply two values:
>> macstl::vec<unsigned, 4> v1 = macstl::vec<unsigned, 4>::set(1, 2, 3, 
>> 4);
>> macstl::vec<unsigned, 4> v2 = macstl::vec<unsigned, 4>::set(1, 2, 3, 
>> 4);
>> v1 += v2; // OK
>> v2 *= v2; // Won't complile :(
>> It says:
>> ..\macstl\vec.h(210) : error C2678: binary '*' : no operator found 
>> which takes
>> a left-hand operand of type 
>> 'macstl::impl::vec_base<D,T,B>::vec_value' (or
>> there is no acceptable conversion).         with
>>         [
>>             D=__m128i,
>>             T=unsigned int,
>>             B=macstl::boolean<int>
>>         ]
>> McSeem

Hope this email gets to the right people, I followed the macstl thread 
on AGG with some interest, and thanks for looking at macstl!

vec <unsigned, 4>::operator* is currently undefined but planned. As 
Tony has said, this would require the PMULUDQ, but because PMULUDQ 
produces a 64-bit element result, I would have to shuffle, do two 
PMULUDQ's and then do an unpack (pack?). So if it's important to you 
guys, I will explore this in 0.2.2, or alternatively you could 
contribute code to that effect (hint: vec_mmx.h:2640).

Altivec is similar, it requires several instructions to get the same 
effect.

vec <unsigned, 2>::operator* has similar issues.

The vec types are all aligned on 16-byte boundaries as are the valarray 
types. So in the rare case that a vec needs to be written or read from 
memory (see next para), it will be done aligned.

As for the usefulness of loading and unloading from EMMX registers, 
I've found that with aggressive compiler optimization on, the vec types 
live totally within a register by design. So the best use of them is to 
perform as many calculations as possible using vec, rather than loading 
and unloading individual elements of vec -- after all, that's what the 
acronym SIMD implies. Indeed, you can use macstl's valarray 
implementation to do calculations on entire arrays transparently and 
efficiently -- you declare valarrays of the scalar element, but the 
implementation transparently upscales using the equivalent SIMD vectors 
if available.


Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com