The current git code and the patched code are fully equivalent to each other. In the unpatched code RefCount is always protected by a mutex and the RefCount adjustment region protects just the RefCount (it doesn't protect anything else) - in the patched code RefCount is always adjusted via p_atomic*().
Because of this equivalence: If the new code contains a bug then the unpatched code must contain the same bug as well. On Wed, Oct 19, 2016 at 9:58 PM, Matt Turner <matts...@gmail.com> wrote: > On Wed, Oct 19, 2016 at 12:06 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote: >> This patch removes locks around reference counts in favor of atomic inc/dec >> operations on the refcounts. This makes the refcount adjustments much faster. > > I had the same idea last year and sent a patch series ([PATCH 00/13] > mesa: Locking improvements and optimizations [1]). > > The part that corresponds to your patch are patches 5-9. 1-4, 10, and > 11 were committed. > > I'm having a difficult time remembering why I ultimately dropped the > series, but Ian's comment on 05/13 indicates that the locking is > broken for bufferobj.c, so it's not appropriate to use atomics there. > I remember that texture locking is totally broken, but I cannot > remember the details. > > The other thing (in 12/13 [2]) is that vertex array objects, > framebuffer objects, and pipeline objects are "container objects" and > are not shared between contexts, so they require no locking. It would > be better to solve that and avoid locking/atomics all together. But > then FBOs (and renderbuffers?) from EXT_framebuffer_object and VAOs > from APPLE_vertex_array_object are actually shared between contexts, > so those are out as well. > > That seems to leave sampler objects, shader objects, and program > objects. I suspect those are relatively small compared with textures > or buffers. > > I'm not really sure what I'd suggest, to be honest. It seems like a > lot of aggravation for a minimal reward if done right. > > [1] https://lists.freedesktop.org/archives/mesa-dev/2015-August/090972.html > [2] https://lists.freedesktop.org/archives/mesa-dev/2015-August/090984.html _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
