[macstl-dev] Re: [Fwd: Multiplication?]
glen.low at pixelglow.com
Mon Feb 28 08:53:25 WST 2005
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.
> Asger Ottar Alstrup
> Maxim Shemanarev wrote:
>>> Check out the macstl project:
>>> It contains a portable library intended for this kind of thing.
>> 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,
>> macstl::vec<unsigned, 4> v2 = macstl::vec<unsigned, 4>::set(1, 2, 3,
>> 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
>> T=unsigned int,
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
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
Cheers, Glen Low
pixelglow software | simply brilliant stuff
More information about the macstl-dev