inefficient TLS access in mesa-gl due to workaround for upstream bug
The commit message here is wrong:
The —disable-glx-tls workaround introduced in that commit uses pthread_key_create/pthread_[gs]etspecific to access the current GL context, which is going to go through a couple layers of function calls, and in principle could fail at runtime if too many keys were already created when the library is loaded.
The root problem here is an upstream bug in mesa:
The right fix is to patch out all instances of attribute((tls_model(“initial-exec”))) from mesa; this patch should also be pushed upstream. The result will be very slightly (probably not measurable) slower than with —enable-glx-tls (which only works when mesa is directly linked, not dlopen’d), but should be a lot faster than with —disable-glx-tls. It could be very slightly sped back up (probably as fast as —enable-glx-tls) using TLSDESC (-mtls-dialect=gnu2) on archs that support it (i386, x86_64, aarch64, and in the future arm).
(from redmine: issue id 9260, created on 2018-08-16)