Mesa Git Master
AMD A8-6600K APU
When playing an h264 video using mpv with vdpau hardware decoding over opengl, the video is corrupted and the following error appears in dmesg:
[ 8936.496231] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:854 texture bo too small (layer size 225280, offset 1126400, max layer 2, depth 1, bo size 1351680) (640 176)
[ 8936.496257] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
If I downgrade mesa to 12.0.3, playback works ok.
Other mpv users have reported the same issue:
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 firstname.lastname@example.org.
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
Author: Brian Paul <email@example.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
- 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
Reviewed-by: Edward O'Callaghan <firstname.lastname@example.org>
Reviewed-by: Nicolai Hähnle <email@example.com>
Reviewed-by: Marek Olšák <firstname.lastname@example.org>
: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.
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
on Feb 24, 2017 at 03:40:42.
(provided by the Example extension).