Posted by
Sven Gothel on
Jan 11, 2011; 2:55am
URL: https://forum.jogamp.org/Multithreading-tp2221001p2232245.html
On Sunday, January 09, 2011 20:34:33 Demoscene Passivist [via jogamp] wrote:
>
> >Hopefully Demoscene or Julien can comment on this -- they've probably got
> direct experience doing it
>
> Not really as I generally avoid multithreading with OpenGL. I've tried
> mutlithreading when I begun with OpenGL but made really discouraging
> experiences regarding driver stability on a lot of platforms. All OpenGL
> calls I do are made from on single thread, tho I do data preprocessing on
> multiple threads to later feed the data to the single "OpenGL-API-Call"
> thread.
>
> So my advise is if u have to release ur application to a broad range of
> different OpenGL drivers: DON'T USE MULTITHREADING! If u know the
> platform/driver implementation and can actively test ur application on that
> setup, feel free to try it out: It may work for u.
I don't agree with this statement when it comes to data streaming,
even though it might be true for just 'the rendering loop'.
As Wade explained, it is a very good and used technique
to stream data to the GPU via async DMA (PBO, ..).
To achieve that all you need to to know where your sync points are,
ie you need a proper application level synchronization to be able to
signal your rendering loop that data is available.
I have used this technique for PBO DMA xfers and OpenMAX,
where your decoder thread fills texture buffers.
You can sync via OpenGL sync points in the stream (or PBO commands),
or high level in your API - your choice.
If you like to use GL in your data thread which fills buffer,
you may need to use a shared GL context, sure.
In the end you may need to experiment which strategy is best as Wade advised.
!Sven