guruofquality
commented
11 years ago On 02/24/2013 03:33 PM, Almohanad (Al) Fayez wrote:
BTW, excellent GRAS intro wiki !! seriously good job. I'm just starting to read things but I have a question about the memcpy for buffer history as mentioned in the gras intro Libre presentation ... is gras physically copying the memory contents to appease the history requirements for the blocks? I've thought about this before and i have a thought and would like your input:
My guess is it's possible to create history "buffers" between blocks and stitch them in a link list manner this way the "link list" history can be disconnected from the end of the buffer and stitched to the beginning for the next cycle
Would this make sense in the gras context? the main downside would be that setting the history parameter might need to be done during initializing the graph and frowned upon mid execution ... personally i think it might speed up flowgraphs ... it might be worth adding it as an option for the user to handle history and i might work on it once i get a handle on things
There has been a lot of good development since that presentation so it might be out of date.
Actually GRAS has no concept of sample history. This is really just something that becomes meaningful when you are making a filter block. History basically means the block reads items, but does not consume them... so the same samples show up in the next call to work. GRAS also has a port config option to preload the buffer with zeros for those filter block authors who like to start with some padding.
Anyway, how do we make this efficient? GRAS allows the user API to replace the input and output buffer allocators. There are two buffer allocators built in: a pool of discontinuous buffers, and a circular buffer allocator. The pool is the default once. However, in the gnuradio wrapper, if the user has set history, the gr block configures the input port allocator to use the circular buffer allocator.
In the scheduler side: When you consume items, chunks of buffers become fragmented. The input handlers perform input stitching if the buffers are contiguous. The memcpying only happens if the buffers are not contiguous and the consumer has requirements that cannot be met without memcpying.
-josh
BTW, excellent GRAS intro wiki !! seriously good job. I'm just starting to read things but I have a question about the memcpy for buffer history as mentioned in the gras intro Libre presentation ... is gras physically copying the memory contents to appease the history requirements for the blocks? I've thought about this before and i have a thought and would like your input:
My guess is it's possible to create history "buffers" between blocks and stitch them in a link list manner this way the "link list" history can be disconnected from the end of the buffer and stitched to the beginning for the next cycle
Would this make sense in the gras context? the main downside would be that setting the history parameter might need to be done during initializing the graph and frowned upon mid execution ... personally i think it might speed up flowgraphs ... it might be worth adding it as an option for the user to handle history and i might work on it once i get a handle on things