Hi Gregory, On Tue, 2017-02-07 at 16:04 +0100, Gregory Hainaut wrote: > > Hi, > > > > On Mon, 2017-02-06 at 13:43 +0100, Jan Ziak wrote: > > > Shadow of Mordor benchmark: 30 FPS w/o glthread -> 20 FPS with > > > glthread > > > > > > > For what it is worth, all the Feral games have a dispatch thread that > > primarily calls GL functions. > > > > James > > > > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
