Re: [Discuss-gnuradio] Using gnu-radio for project
On Tue, Sep 30, 2008 at 02:50:50PM -0400, Philip Balister wrote: > On Tue, Sep 30, 2008 at 2:43 PM, Eric Blossom <[EMAIL PROTECTED]> 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. Yep, me too. > >> 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- 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? Nobody. However, they have provided over 1000 pages of detailed documentation on their API. Since a big part of any effort is figuring out what the API should be, I'd prefer to use theirs (and their documentation) than to reinvent the wheel. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Using gnu-radio for project
I agree with this because of the Beagle board and the efficacy of OMAP processors for embedded SDR apps. With TI finally giving us free development tools for noncommercial activities (not exactly GPL v3) the 6000 DSP part on the OMAP and the Neon are both sources of considerable MIPS at very low power. We should think about how to officially support libraries based on open source we develop but for which there are NO free tools for some of the more interesting parts coming out way including Cell, OMAP, Tilera Tile64, and more. We are doing this now for USRP2. It is time to make a simple policy statement that open source, but binary support is accepted and encouraged given these conditions: A), B), Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "Trample the slow Hurdle the dead" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Balister Sent: Tuesday, September 30, 2008 2:03 PM To: Eric Blossom; Inderaj Bains; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Using gnu-radio for project On Tue, Sep 30, 2008 at 1:48 PM, Eric Blossom <[EMAIL PROTECTED]> wrote: > On Mon, Sep 29, 2008 at 03:13:09PM -0700, Inderaj Bains wrote: >> Thanks Eric, >> Yes I want to use SIMD. Since I want to spend most time improving >> performance, it would be nice if I can start off from something functioning >> or put together something quickly. >> How much effort would it be to get a GSM (other?) all software system >> together (except A/D I guess). Maybe I could use pre-generated streams on >> both ends in software. >> >> Thanks >> Inderaj > > 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/Bcfjicf j.html. Sorry it si the superseded link, I'm too lazy to find the current one :) > 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/34649 9.pdf > > http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/34653 2_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 :) Philip > Framewave http://framewave.sourceforge.net (x86 and x86-64 only) > > (Framewave is built on top of SSEPlus, a thin wrapper on top of the SSE > C/C++ intrinsics. http://sseplus.sourceforge.net > Mostly it appears that they provide emulations for instructions that > are missing at a particular level. E.g., your code could target SSE3, > and they'd emulate the missing addsub instruction in terms of SSE.) > > > For starters, it would be great if you could look at these two options > (and any others that you come across) and let us know how you think > these would work out as starting points, given the requirements above. > > If this seems like more than you want to bite off, I can provide a > list of high-priority functions and you could start implementing the > reference version and any of the SSE*, Altivec or SPE versions that > grab your attention. We're big on complex arithmetic :-) > > Please let me know how this sounds and if you've got any comments or questions. > > Thanks! > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for project
On Tue, Sep 30, 2008 at 2:43 PM, Eric Blossom <[EMAIL PROTECTED]> 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- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for project
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 :-) > > 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- in the framework, and that the intel function naming convention doesn't map well (at all?) into the liboil framework. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for project
On Tue, Sep 30, 2008 at 1:48 PM, Eric Blossom <[EMAIL PROTECTED]> wrote: > On Mon, Sep 29, 2008 at 03:13:09PM -0700, Inderaj Bains wrote: >> Thanks Eric, >> Yes I want to use SIMD. Since I want to spend most time improving >> performance, it would be nice if I can start off from something functioning >> or put together something quickly. >> How much effort would it be to get a GSM (other?) all software system >> together (except A/D I guess). Maybe I could use pre-generated streams on >> both ends in software. >> >> Thanks >> Inderaj > > 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 :) > 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 :) Philip > Framewave http://framewave.sourceforge.net (x86 and x86-64 only) > > (Framewave is built on top of SSEPlus, a thin wrapper on top of the SSE > C/C++ intrinsics. http://sseplus.sourceforge.net > Mostly it appears that they provide emulations for instructions that > are missing at a particular level. E.g., your code could target SSE3, > and they'd emulate the missing addsub instruction in terms of SSE.) > > > For starters, it would be great if you could look at these two options > (and any others that you come across) and let us know how you think > these would work out as starting points, given the requirements above. > > If this seems like more than you want to bite off, I can provide a > list of high-priority functions and you could start implementing the > reference version and any of the SSE*, Altivec or SPE versions that > grab your attention. We're big on complex arithmetic :-) > > Please let me know how this sounds and if you've got any comments or > questions. > > Thanks! > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for project
On Mon, Sep 29, 2008 at 03:13:09PM -0700, Inderaj Bains wrote: > Thanks Eric, > Yes I want to use SIMD. Since I want to spend most time improving > performance, it would be nice if I can start off from something functioning > or put together something quickly. > How much effort would it be to get a GSM (other?) all software system > together (except A/D I guess). Maybe I could use pre-generated streams on > both ends in software. > > Thanks > Inderaj 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. 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) Framewave http://framewave.sourceforge.net (x86 and x86-64 only) (Framewave is built on top of SSEPlus, a thin wrapper on top of the SSE C/C++ intrinsics. http://sseplus.sourceforge.net Mostly it appears that they provide emulations for instructions that are missing at a particular level. E.g., your code could target SSE3, and they'd emulate the missing addsub instruction in terms of SSE.) For starters, it would be great if you could look at these two options (and any others that you come across) and let us know how you think these would work out as starting points, given the requirements above. If this seems like more than you want to bite off, I can provide a list of high-priority functions and you could start implementing the reference version and any of the SSE*, Altivec or SPE versions that grab your attention. We're big on complex arithmetic :-) Please let me know how this sounds and if you've got any comments or questions. Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for project
Thanks Eric, Yes I want to use SIMD. Since I want to spend most time improving performance, it would be nice if I can start off from something functioning or put together something quickly. How much effort would it be to get a GSM (other?) all software system together (except A/D I guess). Maybe I could use pre-generated streams on both ends in software. Thanks Inderaj On Mon, Sep 29, 2008 at 11:47 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: > On Sat, Sep 27, 2008 at 03:37:34PM -0700, Inderaj Bains wrote: > > Dear Friends, > > > > For a school project, I am looking to speed up a software radio. > > I downloaded and built gnu-radio and dial-tone works. > > > > Ideally, I'd like to start with a functioning GSM (others?) radio > > which runs in software and speed up the computationally intensive > > components (which gnu radio might be using the fpga for) > > Good. Are you thinking about using various SIMD instruction sets, or > something else? > > > PS. I have no background in dsp/signal-processing but have good > > programming background and my day job is writing compilers. > > Eric > -- ~Inderaj ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using gnu-radio for project
On Sat, Sep 27, 2008 at 03:37:34PM -0700, Inderaj Bains wrote: > Dear Friends, > > For a school project, I am looking to speed up a software radio. > I downloaded and built gnu-radio and dial-tone works. > > Ideally, I'd like to start with a functioning GSM (others?) radio > which runs in software and speed up the computationally intensive > components (which gnu radio might be using the fpga for) Good. Are you thinking about using various SIMD instruction sets, or something else? > PS. I have no background in dsp/signal-processing but have good > programming background and my day job is writing compilers. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using gnu-radio for project
Dear Friends, For a school project, I am looking to speed up a software radio. I downloaded and built gnu-radio and dial-tone works. Ideally, I'd like to start with a functioning GSM (others?) radio which runs in software and speed up the computationally intensive components (which gnu radio might be using the fpga for) I would really appreciate if someone could help me in trying to figure out if/how gnu-radio is a good fit and/or point to other open source projects. Thanks, -Bains PS. I have no background in dsp/signal-processing but have good programming background and my day job is writing compilers. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
