Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK

[Tom Rondeau]

On Mon, Feb 24, 2014 at 12:15 AM, West, Nathan
<address@hidden> wrote:
> On Sun, Feb 23, 2014 at 12:52 AM, Abhishek Bhowmick
> <address@hidden> wrote:
>> Hello,
>> I have completed a Bachelor's degree in Electrical Engineering from IIT
>> Bombay, India and will be joining a masters program in Computer Science in
>> August. For the summer, I am interested in participating GSoC 2014 and GNU
>> Radio is an organization where my background fits nicely.
>>
>> I went through the ideas page and was particularly interested in doing
>> performance optimization with VOLK.
>
> Great to hear. Just keep in mind we have another ~13 hours before we
> as an organization
> know whether we were accepted or not.
>
>> After going through some online
>> documentation about the library and the SDR'12 paper, I realised that
>> following areas need work :
>> 1. Profiling GNU radio code to identify new kernels and implement them for
>> existing Intel SIMD extensions, also porting kernels to other ISA
>> extensions.
>> 2. Better testing of the effects of more complex scheduler logic on larger
>> environments (beyond simple kernels)
>> 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD
>> Fusion (However, this seems to more research than software development)
>>
>> According to the GSoC proposal, point (1) seems to be the expectation. Given
>> this, I would like some advice on how to go ahead looking for potential
>> ideas (and some feedback on feasibility of the other ideas as well)
>>
>> My background : C++, Python, Signal Processing, Computer Architecture
>>
>> Thanks,
>> Abhishek Bhowmick
>>
>
> Abhishek,
>
> Right, so points 1 and 2 are what I had in mind when I wrote the idea
> on our list. Point 3
> is technically possible to do in VOLK, but probably not really worth
> using GPUs in this way
> since the transport costs would dwarf any acceleration from the
> current VOLK kernel. That said,
> there's nothing really wrong with a proposal that is on a research
> area, but I do think we would want
> code and something contributed back to the community at the end of the
> project. Also, don't let that
> prevent you from submitting a proposal about GPU programming if that's
> what you're interested in, it's
> probably just not best targeted for VOLK. My understanding of GSoC
> proposals is that you can submit
> any number,so you can submit one for doing some GPU acceleration and
> another for something more
> related to VOLK.


I agree with Nathan that VOLK is probably not the right abstraction
for GPUs. The Fusion concept with the GPU and GPP on the same die is
compelling, but maybe too specific. There is another project called
gr-gpu that's focusing on the GPU problem more generally.

> So for points 1 and 2 it would be good to see a specific algorithm or
> module that you think would
> benefit from moving to VOLK, which would take some research on your
> part. I think gr-atsc is a
> good place to look for some acceleration gains, and it would be good
> to see that application run
> real time. One of the things I had in mind is accelerating OFDM frame
> sync. Martin's ofdm_{rx,tx}
> and gr-80211 are good examples where they use blocks that have VOLK
> kernels in them to do the
> sync, but that's somewhat inefficient because we move data in and out
> of SIMD registers. Of course
> there's the old trade-off of modularization and code re-use vs. speed.
> I'd be glad to discuss this and
> similar ideas more once we know we are accepted as an org. There's one
> more possibility that recently
> came up, but I'd like to wait until things are official before
> recommending it (and I'll need to talk with
> other interested parties).

We're working with Andrew Davis on updating gr-atsc
(https://github.com/glneo/gnuradio/tree/atscfixup). If you decide to
focus on ATSC speedups with VOLK, look into that project instead of
the one inside gnuradio (which will be deprecated).

Tom


> At the moment the only mainstream ISA not being targeted is probably
> AVX2, which has
> some nice features for the type of kernels we're doing.  If you went
> that route it would likely need add
> protokernels to a pretty large number of kernels.
>
> Nathan