diff options
author | Nicolai Hähnle <[email protected]> | 2017-10-22 17:38:36 +0200 |
---|---|---|
committer | Nicolai Hähnle <[email protected]> | 2017-11-09 11:50:55 +0100 |
commit | 637240d824051b8b99f35c165cabe31106612f2a (patch) | |
tree | a0fa593530357172edf6414f5b6548dc9cc88e7e /src/gallium/drivers/softpipe/sp_fence.c | |
parent | 8d20c660a9831c367d98ed2fea25e5276e6466f2 (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/softpipe/sp_fence.c')
0 files changed, 0 insertions, 0 deletions