[Mesa-dev] [PATCH] mesa: avoid pthread_mutexes when adjusting object refcounts

[Jan Ziak]

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 <mattst88 at gmail.com> wrote:
> On Wed, Oct 19, 2016 at 12:06 PM, Jan Ziak <0xe2.0x9a.0x9b at 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