GRCon14CoProc

From GNU Radio
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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)