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.

I'm a newbie at this, so I posted to the mpv bug tracker if anyone there can bisect (https://github.com/mpv-player/mpv/issues/3714).

If no one volunteers soon, then I'll give it a try.

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

Well done, thanks for that.

Brian, Marek, Nicolai any idea what's causing this?

This works just fine on radeonsi, so it's likely an r600-specific problem that happened to be uncovered by that commit. Have you tried running with a debug build of Mesa?

(In reply to Nicolai Hähnle from comment #5)
> This works just fine on radeonsi, so it's likely an r600-specific problem
> that happened to be uncovered by that commit. Have you tried running with a
> debug build of Mesa?

FWIW on si this commit will assert with a debug build, there is also the pre existing issue on si where vdpau hwdec + opengl vo only renders half the lines.

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

Yeah, on SI we don't have a kernel command stream parser to double check those things.

So instead of an error message you probably just get incorrect rendering for maybe one frame or two.

Hmm, so why don't I see that assertion? Following the linked mpv-player github issue, I'm running

$ mpv --hwdec=auto Videos/Serenity.Trailer.H264.mp4

on a radeonsi debug build just fine. The log on the command line looks just like the one of the reporter of the github issue. What flags am I missing?

(In reply to Nicolai Hähnle from comment #8)
> What flags am I missing?

Just an educated guess, but try adding "-vo opengl" to the command line.

(In reply to Nicolai Hähnle from comment #8)
> Hmm, so why don't I see that assertion? Following the linked mpv-player
> github issue, I'm running
> 
> $ mpv --hwdec=auto Videos/Serenity.Trailer.H264.mp4
> 
> on a radeonsi debug build just fine. The log on the command line looks just
> like the one of the reporter of the github issue. What flags am I missing?

It doesn't happen with older mpv, not sure what date it changed.

The -vo=opengl makes no difference. The one suspicious thing I'm seeing is:

Mesa: User error: GL_INVALID_OPERATION in VDPAUFiniNV

but mpv does call VDPAUInitNV later without error, and shows no other complaints. And I've double-checked that the driver .so's that it loads really are from my debug build, and if I manually add an assertion somewhere in the driver, that does trigger. It's probably something stupid that I'm missing.

Andy, that's it. With an upgraded mpv, I get the assertion as well. I'm going to look into it.

I think I understand the problem. https://patchwork.freedesktop.org/patch/119855/ fixes the issue for me, could you please check that it fixes r600 as well?

(In reply to Nicolai Hähnle from comment #13)
> I think I understand the problem.
> https://patchwork.freedesktop.org/patch/119855/ fixes the issue for me,
> could you please check that it fixes r600 as well?


Confirmed, patch fixes issue for me with AMD A8-6600K APU.

The fix is in Mesa master, commit 322483f71b068b3bbf69e5434e888f3fd3f4589e