diff options
author | Nicolai Hähnle <[email protected]> | 2016-11-03 21:49:40 +0100 |
---|---|---|
committer | Nicolai Hähnle <[email protected]> | 2016-11-04 21:26:29 +0100 |
commit | 322483f71b068b3bbf69e5434e888f3fd3f4589e (patch) | |
tree | 6e836b6d1187dd859083505797c875d3c5104a57 /src/gallium/drivers/radeonsi/si_state.h | |
parent | d0d5f7600c2e8ab8d0c153787185f7a534753edd (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 'src/gallium/drivers/radeonsi/si_state.h')
0 files changed, 0 insertions, 0 deletions