Hi Doug,
Great ! Very interesting work.
> (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 ?
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().
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
