> > >* 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 ^^).
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
