[Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Gregory Hainaut]

>
> >* Hello James,
> *> > >* Did you have the opportunity to compare Feral's dispatcher threading
> *>* implementation versus Nvidia's threading option. If yes, is there any
> *>* performance difference? In other word, did you implement it because
> *>* some (most) drivers miss this optimization or because it can really
> *>* bring some performance improvements (when done carefully).
> *
> 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
>
>
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 ^^).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170208/5a507782/attachment.html>