On Mon, Jul 13, 2015 at 10:37 AM, Douglas Geiger < [email protected]> wrote:
> On Mon, Jul 13, 2015 at 3:03 AM, Sylvain Munaut <[email protected]> wrote: > >> >> 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. > > Sylvain, Perhaps buffer creation can be done in init() and the block can mmap(...) the buffer in its own thread. Is there a good way to keep track of read/write pointers if this is done? -Nathan
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
