summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/etnaviv/etnaviv_shader.c
diff options
context:
space:
mode:
authorNicolai Hähnle <[email protected]>2017-10-22 17:38:36 +0200
committerNicolai Hähnle <[email protected]>2017-11-09 11:50:55 +0100
commit637240d824051b8b99f35c165cabe31106612f2a (patch)
treea0fa593530357172edf6414f5b6548dc9cc88e7e /src/gallium/drivers/etnaviv/etnaviv_shader.c
parent8d20c660a9831c367d98ed2fea25e5276e6466f2 (diff)
st/mesa: guard sampler views changes with a mutex
Some locking is unfortunately required, because well-formed GL programs can have multiple threads racing to access the same texture, e.g.: two threads/contexts rendering from the same texture, or one thread destroying a context while the other is rendering from or modifying a texture. Since even the simple mutex caused noticable slowdowns in the piglit drawoverhead micro-benchmark, this patch uses a slightly more involved approach to keep locks out of the fast path: - the initial lookup of sampler views happens without taking a lock - a per-texture lock is only taken when we have to modify the sampler view(s) - since each thread mostly operates only on the entry corresponding to its context, the main issue is re-allocation of the sampler view array when it needs to be grown, but the old copy is not freed Old copies of the sampler views array are kept around in a linked list until the entire texture object is deleted. The total memory wasted in this way is roughly equal to the size of the current sampler views array. Fixes non-deterministic memory corruption in some dEQP-EGL.functional.sharing.gles2.multithread.* tests, e.g. dEQP-EGL.functional.sharing.gles2.multithread.simple.images.texture_source.create_texture_render Reviewed-by: Marek Olšák <[email protected]>
Diffstat (limited to 'src/gallium/drivers/etnaviv/etnaviv_shader.c')
0 files changed, 0 insertions, 0 deletions