summaryrefslogtreecommitdiffstats
path: root/install-lib-links.mk
diff options
context:
space:
mode:
authorNicolai Hähnle <[email protected]>2016-11-03 21:49:40 +0100
committerNicolai Hähnle <[email protected]>2016-11-04 21:26:29 +0100
commit322483f71b068b3bbf69e5434e888f3fd3f4589e (patch)
tree6e836b6d1187dd859083505797c875d3c5104a57 /install-lib-links.mk
parentd0d5f7600c2e8ab8d0c153787185f7a534753edd (diff)
st/mesa: fix the layer of VDPAU surface samplers
A (latent) bug in VDPAU interop was exposed by commit e5cc84dd43be066c1dd418e32f5ad258e31a150a. Before that commit, the st_vdpau code created samplers with first_layer == last_layer == 1 that the general texture handling code would immediately delete and re-create, because the layer does not match the information in the GL texture object. This was correct behavior at least in the DMABUF case, because the imported resource is supposed to have the correct offset already applied. In the non-DMABUF case, this was just plain wrong but apparently nobody noticed. After that commit, the state tracker assumes that an existing sampler is correct at all times. Existing samplers are supposed to be deleted when they may become invalid, and they will be created on-demand. This meant that the sampler with first_layer == last_layer == 1 stuck around, leading to rendering artefacts (on radeonsi), command stream failures (on r600), and assertions (in debug builds everywhere). This patch fixes the problem by simply not creating a sampler at all in st_vdpau_map_surface. We rely on the generic texture code to do the right thing, adding the layer_override to make the non-DMABUF case work. v2: add the layer_override Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98512 Cc: 13.0 <[email protected]> Cc: Christian König <[email protected]> Cc: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> (v1) Reviewed-by: Christian König <[email protected]>
Diffstat (limited to 'install-lib-links.mk')
0 files changed, 0 insertions, 0 deletions