GRCon14CoProc

GRCon14CoProc

The Co-Processors Working Group met on Wednesday 9/17 at 15:30 Eastern (3:30pm local time in DC) (For conference schedule see http://www.trondeau.com/grcon14-agenda/). The schedule gave us approximately 2 hours dedicated to Co-Processors discussion.

Agenda

• Hardware Specific Problems
  

What is needed on a per-device basis

• • Best-practices
  • Skeleton framework to be filled in for each device

• Non-Hardware Specific
  

What can we do in mainline GNURadio to help all co-processors

• • Memory transfer
    • Marking blocks as 'accelerated' (i.e. Alfredo Muniz's patchset from GSoC'14 - see https://github.com/muniza/gnuradio)
    • Other efforts (e.g. Jonathan Pendlum: Zynq FPGA fabric, gr-dsp, gr-gpu)
  • Scheduling
    • Fine-grained control over number of items to be processed per 'work' call
    • Message passing

Meeting Notes

Discussion Highlights

The discussion around what needs changing in mainline GNURadio ended up revolving around three general cases:

1. Hardware supports scatter/gather DMA: the driver does the hard part (e.g. GPU's, Zynq generally behave well)
   • No changes are needed to GNURadio's buffer management, however the buffer base/length should be more accessible to the work() function
2. Hardware doesn't support scatter/gather (i.e. it requires contiguous memory):
   • GNURadio needs to support blocks with custom allocators (i.e. signal to the scheduler that a block handles it's own buffers)
   • GNURadio also needs to handle the case that the custom allocator cannot support doubly-mapped buffers (i.e. signal that a buffer is only singly-mapped)
     • The scheduler can handle this by ensuring that a call to work() would never cross the end boundary
3. Broken hardware + bad driver
   • Complain to the vendor
   • Use memcpy, and return to case 1

Tasks

Outstanding work that needs addressing can be broken up into the following tasks

1. Make buffer location (base/length) available to work() function (#729)
2. Allow blocks to specify they need custom buffer allocators (#730)
3. Handle non-doubly-mapped buffers appropriately (i.e. call work() with number of items to make sure the end of the buffer is not crossed) (#731)
4. Block/Buffer life-cycle management (#730)
   • init()/@make_ready()@ function to ensure buffers are allocated before start() is called for blocks with custom allocators
   • shutdown()/@destroy()@ function to ensure buffers are freed when the top_block is destroyed
5. Notify block (e.g. via callback mechanism) when read pointer has moved, and when write pointer has moved (#732)