Re: [Mesa-dev] [PATCH 0/6] st/mesa: add locking around lazy texture/sampler updates

2017-10-06 Thread Roland Scheidegger
Am 07.10.2017 um 01:01 schrieb Nicolai Hähnle: > On 07.10.2017 00:36, Roland Scheidegger wrote: >> I can't help but think that there'd be none of those problems if those >> views were actually used as specced by gallium initially: all sampler >> views (and surfaces) are per context, and they simply

Re: [Mesa-dev] [PATCH 0/6] st/mesa: add locking around lazy texture/sampler updates

2017-10-06 Thread Nicolai Hähnle
On 07.10.2017 00:36, Roland Scheidegger wrote: I can't help but think that there'd be none of those problems if those views were actually used as specced by gallium initially: all sampler views (and surfaces) are per context, and they simply cannot be used in another context. That is actually t

Re: [Mesa-dev] [PATCH 0/6] st/mesa: add locking around lazy texture/sampler updates

2017-10-06 Thread Roland Scheidegger
I can't help but think that there'd be none of those problems if those views were actually used as specced by gallium initially: all sampler views (and surfaces) are per context, and they simply cannot be used in another context. Roland Am 06.10.2017 um 22:38 schrieb Nicolai Hähnle: > Hi all, >

[Mesa-dev] [PATCH 0/6] st/mesa: add locking around lazy texture/sampler updates

2017-10-06 Thread Nicolai Hähnle
Hi all, This series is a first result of debugging some random crashes in dEQP's multi-threaded EGL tests. The OpenGL spec is pretty clear that application must not modify a texture in one context while simultaneously using it for texturing (or even modifying) it in another context. Texturing sim