GRCon14CoProc

From GNU Radio
Jump to: navigation, search

GRCon14CoProc[edit]

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[edit]

  • 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[edit]

Discussion Highlights[edit]

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[edit]

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)