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

begin:vcard
fn:Johnathan Corgan
n:Corgan;Johnathan
org:Corgan Enterprises LLC dba Corgan Labs
adr:;;6081 Meridian Ave. Suite 70-111;San Jose;CA;95120;United States
email;internet:johnathan@corganlabs.com
title:Managing Partner
tel;work:+1 408 463 6614
x-mozilla-html:FALSE
url:http://corganlabs.com
version:2.1
end:vcard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iF4EAREIAAYFAlJ6sc4ACgkQRzB3vGcdovfyIwD+LpH1qLumejT0nBGdw7xHhhsZ
VChXNgs5D7fXzrZEu6QA/RuALctODFeW1jvyg0KqYjyl4h56Z4m987dWLmtrEG0A
=bEBT
-----END PGP SIGNATURE-----
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