Re: [Discuss-gnuradio] Using gnu-radio for project

[Philip Balister]

On Tue, Sep 30, 2008 at 2:43 PM, Eric Blossom <address@hidden> wrote:
> On Tue, Sep 30, 2008 at 02:03:14PM -0400, Philip Balister wrote:
>> > This is great.  What we've been thinking about is building a library
>> > of SIMD accelerated primitives, along the lines of Intel's Integrated
>> > Performance Primitives.  The crucial differences would be: free
>> > software (GPLv3); support for SSE, SSE2, SSE3, Altivec and Cell SPE
>> > instruction sets.
>>
>> Do you mind adding NEON to this list?  NEON is a SIMD unit on ARM
>> Cortex-A8 processors. Information on NEON instructions is at
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicfj.html.
>> Sorry it si the superseded link, I'm too lazy to find the current one
>> :)
>
>
> NEON's fine by me, as long as you're doing the work :-)

I just want to make sure the work has somewhere to go.

>
>
>> > Our working title for this is the "Generic Performance Primtives" (GPP).
>> >
>> > One unresolved issue is what code to start with.  We need a framework
>> > that provides for reference implementations, QA, testing all argument
>> > alignments, correctness, performance, etc; runtime dispatch based on
>> > the equivalent of cpuid; can be built as both shared and static
>> > libraries (need static on the SPE).
>> >
>> > The basic idea (for the user visible routines) would be to start with
>> > the well thought out API described in Volume 1 (Signal Processing) of
>> > the IPP docs, peforming a s/ipp/gpp/g.
>> >
>> >  
>> > http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/346499.pdf
>> >
>> >  
>> > http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/346532_userguide_win_ia32.pdf
>> >
>> >
>> > Two possible starting points are:
>> >
>> >  liboil      http://liboil.sourceforge.net    (currently x86, x86-64 and 
>> > PPC)
>>
>> liboil is used by a number of desktop programs, spending time on this
>> would be a win for me :)
>
> The issues I see with it is that there's currently no support for
> complex-<anything> in the framework, and that the intel function naming
> convention doesn't map well (at all?) into the liboil framework.

Well, who said it was an Intel dominated world?

Philip