On 11/06/2013 12:58 PM, Sylvain Munaut wrote: > 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.
Unfortunately, this moves the knowledge of how a domain works into GNU Radio, and away from the code/coders that know about it. It would mean that any time a different co-processor or hardware offload design comes up, GNU Radio itself would have to change, and designers would have to have knowledge of GNU Radio internals in order to develop their code. I suggest that a way to implement domain-specific knowledge across multiple blocks, allowing the kind of optimization you describe above, would be to make a parent class for each domain that the blocks of that type all derive from. In the parent class, static instance variables/methods would be able to maintain the overall state needed to coordinate the activities of the instances of the derived classes that are sharing that domain. The code developer then only needs to have the domain-specific knowledge of how to create memory buffers usable by GNU Radio and work with the co-processor. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com
<<attachment: johnathan.vcf>>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
