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 >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
