Hi,
>> 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.
When you want to share a buffer between OpenCL and OpenGL is that you
create the OpenGL object (like a texture or VBO buffer), then you
share it to OpenCL so you can access it using OpenCL.
So, you can't actually create it or do anything until you can create
that GL object and that only happens when the UI is up and ready.
However now that I think about it, this is irrelevant for sample data
since those are not shared with GL. They're pure CL. It's just that I
have a single "init" method and so I wasn't seeing them as separate.
Now for purely OpenCL buffers, you could create them before hand. In
theory OpenCL supports multi-threading. However theory and practice
don't always match and I've seen some implementation just fail
miserably there. Hopefully the init in one thread then do everything
in the other and never real mix operations between threads should be a
straight forward case enough to work.
But TBH, the more I think about it, the less I think it matters at all
because you can't have a buffer being mapped by the host while it's
bein used by the GPU, nor can you map it twice like GR does. So the
whole idea of writing to CL buffer directly using GR is just not
practical. (it'd need more of a ping pong buffer structure than a
continuous FIFO).
What would be more useful is the ability to force a very large input
buffer size, but that's a completely different issue.
> 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?
Nope, see above.
Cheers,
Sylvain
PS: Also note that currently this is purely theoretical since fosphor
only has inputs, no outputs so no output buffers.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
