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

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)
 * 2) * No changes are needed to GNURadio's buffer management, however the buffer base/length should be more accessible to the  function
 * 3) Hardware doesn't support scatter/gather (i.e. it requires contiguous memory):
 * 4) * GNURadio needs to support blocks with custom allocators (i.e. signal to the scheduler that a block handles it's own buffers)
 * 5) * 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)
 * 6) ** The scheduler can handle this by ensuring that a call to  would never cross the end boundary
 * 7) Broken hardware + bad driver
 * 8) * Complain to the vendor
 * 9) * 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   function (#729)
 * 2) Allow blocks to specify they need custom buffer allocators (#730)
 * 3) Handle non-doubly-mapped buffers appropriately (i.e. call   with number of items to make sure the end of the buffer is not crossed) (#731)
 * 4) Block/Buffer life-cycle management (#730)
 * 5) * /@make_ready@ function to ensure buffers are allocated before   is called for blocks with custom allocators
 * 6) * /@destroy@ function to ensure buffers are freed when the top_block is destroyed
 * 7) Notify block (e.g. via callback mechanism) when read pointer has moved, and when write pointer has moved (#732)