[vsipl++] [patch] Support for Cell FFT's up to 4K points.

[Stefan Seefeld]

Don McCoy wrote:

>> [5] 128 is probably a good alignment.  However, it is kind of a magic
>> number that should be a macro (VSIP_IMPL_CELL_DMAALIGNMENT, pick a
>> good name) to call it out.
>>
> Changed to VSIP_IMPL_ALLOC_ALIGNMENT, and am compiling with
> --with-alignment=128.  I can't think of a compelling reason to make a
> new macro here, but if someone else can, please identify it.

I think this is the right thing to do.
Jules, we quickly talked about this in the past: should we make the implicit
memory allocation used by Dense<> (i.e. when not using user-storage) use
alloc_align<> instead of 'new' ?

>> [8] Do we really have a real->complex FFT on the SPE?
>>
> No, but we could implement these variations fairly easily by putting in
> an extra copy in the dispatcher.  I'll address this soon.

Are you referring to dispatching a real FFT to complex FFT ? I don't think
this is a good idea. Doing a real FFT should be substantially faster than
a complex FFT, and take much less memory.

>> Also, I don't see how you could check for unit-stride here since there
>> is no layout info.  I need to refresh my memory on rt_valid for FFT
>> dispatch a bit.
>>
> I was looking at the serial expression dispatch code, which of course is
> different.  I'd like to understand how this is handled in the FFT code
> though.

Data layout is checked in the operator() implementation(s). Have a look at
vsip/opt/workspace.hpp:97. We assume unit-stride is supported by all backends,
so we have a 'fast path' for it.
In other cases we first need to query the backend whether it supports the
given layout, by calling backend->query_layout(), passing in the actual
layout, and getting back a modified layout that would be accepted.
Based on this we construct an 'Rt_ext_data' object that will make the
necessary adjustments (i.e. possibly do a copy internally).

So, as a backend implementer, you should look at the default implementation
in vsip/core/fft/backend.hpp:51, possibly overriding this from the cbe backends.

> Although this did remind me that we are not passing any flags to the SPU
> compiler like -Wall.  I changed this to do the following:
> 
>    CC_SPU_FLAGS := @CXXFLAGS@
> 
> Which passes any PPU flags from the configure line on to the SPU
> compiler.  Is this ok, at least for now?

This should be

CC_SPU_FLAGS := @CFLAGS@,

since CXXFLAGS may contain C++-specific flags that are not valid when compiling
C. In the long run we should think of setting CC_SPU_FLAGS from within configure.ac,
the same way CFLAGS and CXXFLAGS are set, so we can predefine the variable, and then
only add to that, instead of overwriting it.

Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718