On Mon, Jul 13, 2015 at 3:03 AM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi Doug, > > > Great ! Very interesting work. > > Thanks! > > (I'm just re-using the make_buffer() function so helpfully provided by > > buffer.h - but one can imagine this would call some external memory > > allocator - e.g. OpenCL, Android ION, etc. - and wrap it up in a > > gr::buffer-derived class), and then provides it to the block_detail via > > set_output(). It also does the checking re: buffer size/max_output_buffer > > that is done in flat_flowgraph::allocate_block_detail(), but that was > > skipped because this block manages it's own output buffers. > > Does the allocation have to be done in this init() or can you defer it > to be done later ? > So currently init() is getting called by either flat_flowgraph::setup_connections or flat_flowgraph::merge_connections. These are called by top_block::start or top_block::restart respectively. So I think the short answer to your question is no. However, if I understand what you want correctly this is exactly late enough for e.g. fosphor, in that the UI should (presumably?) already exist, and therefore the GL context should be valid. > Just thinking about my particuliar experience with fosphor, the > allocation can only be done in a very specific context : > > - The UI (Qt/WX/...) has to be fully setup because I need a valid GL > context which will not be available until UI is ready. > > - Allocation needs to be done in the same thread as the one that will > do the work(). > This is tricky - since this is all being handled as part of top_block::start, and in particular even before the scheduler (which, by default, is thread-per-block) is created. Is this a requirement of OpenCL? It is not sufficient that the memory was allocated in the same process? I'll note that at the current point init() is called, the threads which will do the work() don't exist yet. > In theory OpenCL in thread-safe. But for one my buffers are shared > with GL context and GL is definitely not thread safe, and also just > because it's supposed to work doesn't mean you can realiably expect > implementations to do things right and in my experience, it works much > smoother if you keep everything in one thread. > > Cheers, > > Sylvain > -- Doug Geiger doug.gei...@bioradiation.net
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
