https://bugs.freedesktop.org/show_bug.cgi?id=98512

--- Comment #1 from Christian König deathsimple@vodafone.de --- Clearly a bug in the part of the stack which uses the 3D engine for scaling and color space conversion.

Can you try to bisect? If you don't know how feel free to contact me by mail on christian.koenig@amd.com.

https://bugs.freedesktop.org/show_bug.cgi?id=98512

--- Comment #3 from jcamp james.campbell@yahoo.com --- I followed the Arch Linux wiki on how to git bisect, and here's the result:

e5cc84dd43be066c1dd418e32f5ad258e31a150a is the first bad commit commit e5cc84dd43be066c1dd418e32f5ad258e31a150a Author: Brian Paul brianp@vmware.com Date: Fri Sep 30 16:41:46 2016 -0600

st/mesa: optimize pipe_sampler_view validation

Before, st_get_texture_sampler_view_from_stobj() did a lot of work to check if the texture parameters matched the sampler view (format, swizzle, min/max lod, first/last layer, etc). We did this every time we validated the texture state.

Now, we use a ctx->Driver.TexParameter() callback and a couple other checks to proactively release texture views when we know that view-related parameters have changed. Then, the validation step is simplified: - Search the texture's list of sampler views (just match the context). - If found, we're done. - Else, create a new sampler view.

There will never be old, out-of-date sampler views attached to texture objects that we have to test.

Most apps create textures and set the texture parameters once. This make sampler view validation much cheaper for that case.

Note that the old texture/sampler comparison code has been converted into a set of assertions to verify that the sampler view is in fact consistent with the texture parameters. This should help to spot any potential regressions.

Reviewed-by: Edward O'Callaghan funfunctor@folklore1984.net Reviewed-by: Nicolai Hähnle nicolai.haehnle@amd.com Reviewed-by: Marek Olšák marek.olsak@amd.com

:040000 040000 33fe9075f262c8bed745dd732cf2047238698d56 194fe6083d5e3155de216a0990d7babb5c49ee8b M src