<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><pre>><i> Hello James,
</i>><i> 
</i>><i> 
</i>><i> Did you have the opportunity to compare Feral's dispatcher threading
</i>><i> implementation versus Nvidia's threading option. If yes, is there any
</i>><i> performance difference? In other word, did you implement it because
</i>><i> some (most) drivers miss this optimization or because it can really
</i>><i> bring some performance improvements (when done carefully).
</i>
We can't directly compare to Nvidia's option, as our threaded GL
implementation is a necessity for us. OpenGL contexts must be bound to
a specific thread, unlike D3D devices, and we have games written for
D3D using multiple threads to dispatch graphics work (and sometimes
using multiple D3D devices from the same thread). We make one dispatch
thread for each GL context to avoid having to unbind the context from a
thread. There is some locking so that only one game thread may submit
to a context's dispatch thread at once, but that locking is very
lightweight compared to what would happen if we repeatedly attached and
detached GL contexts on game threads. GL_KHR_context_flush_control was
supposed to help with that, by allowing opting out of flushing the GL
context when unbinding it from a thread, but last time we tried that,
there were some synchronous X requests in SDL2 making it remain slow.

Having said that, we did at one point have a path which used
GLX_MESA_multithreaded_make_current when it was available. We found the
GL dispatch threads was quicker on all the games we were working on at
the time.

James</pre></blockquote><div><br></div><div>Oh I see. I already got similar context threading issue when I ported my app from Dx to GL. Thanks  for the full explanation (and for all games ported on Linux ^^).<br></div></div>