Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Ben Hilburn]

Awesome write-up, Johnathan. I really enjoyed reading it.

A few topological problems arise that aren't solved yet by this, such as
having adjacent accelerator blocks that both want to own the shared
memory buffer.  The suggestion here is to use the above mechanism to
create a domain crossing "sink" block and a domain crossing "source"
block as endpoints in a hierarchical block that also instantiates
whatever logic is needed to do the chained accelerators inside.

This goes back to the "ingress" and "egress" blocks that Justin's team used in their original design.

I think having these transitions represented with such blocks makes sense, from a graphical perspective, but under-the-hood I think we should architect these "gresses" as zero-copies. How that relationship / responsibility gets controlled & delegated is something we still need to figure out, I think.

 

Thus, again with minimally invasive changes to the GNU Radio internals,
this mechanism supports both single accelerator blocks as well as the
domain crossing sources and sinks.

Yeah, this is a big selling point of the design, I think.

Finally, this solution is orthogonal to the desired capability of having
in-place processing blocks.  It can be implemented fairly rapidly, even
in a 3.7 API compatible way, and gives the hooks for additional work to
implement block's requesting in-place semantics vs. the existing
streaming semantics.

Right, and this is the key, I think. This problem has to be solved in a "coproc / accelerator"-independent way; otherwise the design would be fundamentally flawed.

Cheers,

Ben

 

--
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com