Hi,
This is an evolution of a concept that was mentioned at GRcon which I
really liked and I thought a bit more about it.
The general idea is that each block and each port within blocks would
have a "domain" associated to it.
For the blocks this would essentially represent where that block is
running, like CPU, DSP, FPGA, GPU
For the ports this would represent where the data are stored Main
memory, GPU memory, page-locked memory for a coproc, shared zone with
a DSP, ...
Once you have those, you'd need ingress/egress blocks to cross over
data domains, they could be either a memcpy on the host, or a
read/write buffer queued in a CL command queue, or whatever is
required. Those wouldn't even need to be really exposed to the user.
GRC/GR-core could be smart enough to find an appropriate path to move
the data from one data domain to the other, it just needs a list of
such available block.
The advantage of introducting this concept to blocks is that for all
the various types of coproc you can think of, the GR core doesn't have
to know anything special and can delegate to appropriate domain
handlers/plugins. Even the CPU domain and Main memory domain would
just be plugins, no special case or anything, they would be treated
just like any other. So coproc aren't "second class citizens", they're
treated just like the main CPU is.
Anyway, just my 2 ct.
Cheers,
Sylvain
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
