Hi > In this design, a block indicates to GNU Radio that it needs to allocate > the memory for either its input buffer (actually, the upstream block's > output buffer) or its own output buffer, by adding a flags field to the > io_signature and having one of the possible flags be WE_OWN.
Well, what I was thinking about is a bit different. The block didn't really did that itself. It was delegated to a "domain" object. The advantages are : - No special casing or flags. The "normal" host buffers as they are now can be handled in the same way. - Since the block doesn't do that itself, that means that several blocks can use the same "domain" object and then, if two blocks are back to back, that object would know how to handle that. If the block does it all itself, two blocks using a GPU for examples couldn't really realize that they're both in the GPU and that there is no need to copy data back to the host at all between them. By delegating those to standardized domain plugins, it would allow to handle those case more gracefully IMHO. Of course this is a bit further from the current architecture but I think the external visible API wouldn't have to change that much when implementing this scheme either. Cheers, Sylvain _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio