[Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

[haagch+mesadev at frickel.club]

On 29.09.2016 01:45, Andy Furniss wrote:
> Mark Thompson wrote:
>> On 28/09/16 11:47, Andy Furniss wrote:
>>> Andy Furniss wrote:
>>>> Andy Furniss wrote:
>>>>
>>>>> I started to get some numbers but found a possible bug = I
>>>>> made a 1000 frame 15mbit 1080p50 mkv with ffmpeg/libx264.
>>>>>
>>>>> Using it as source for transcode (s/w or h/w dec) it came out
>>>>> far too low bitrate.
>>>>>
>>>>> After re-applying debugging patch to mesa it turns out that
>>>>> framerate is being set as 1000 in the encoder, I don't know if
>>>>> the file is duff or if it's the patches.
>>>>>
>>>>> more tomorrow.
>>>>
>>>> Still happens with your libav patch 1 and 2 reversed.
>>>>
>>>> No matter what I try it seems that mkv + hwupload will be seen
>>>> as 1000 fps.
>>>>
>>>> With mp4 it's 25fps.
>>>
>>> Oops ignore the mp4 bit, it is possible to get that to work - no
>>> luck with mkv so far though.
>>>
>>>>
>>>> Also the same with a mkv not made by me, these file all play at
>>>> correct rate and are seen by avconv -i or mediainfo as correct.
>>>>
>>>> I guess there is a difference between reading the fps from the
>>>> container vs reading from the stream.
>>
>> VAAPI CBR does not support VFR input; you end up with the 1000fps
>> because that's the time base inside your input file and we have no
>> way of knowing at init-time what the frame timestamps are going to
>> be.  To make it work, either use CQP (which works sensibly with VFR
>> streams if the container supports them), or make the stream CFR -
>> this is probably easiest by adding "-r 42" (or similar) as an output
>> option.  The mp4 output will not exhibit the problem because the
>> muxer declares in advance that it is CFR-only, so avconv already
>> forces the time base and timestamps into the right state for it.
>
> Ugh, yea, after spending far too much time messing around with input it
> was output format that made the difference.
>
> On bench marking - your 30 vs 250 does seem low. If you haven't tried
> setting gpu and cpu to perf maybe that will help. It helps with my tonga
> sometimes.
>
> If it's a dual GPU system that may add complications as I recall  seeing
> a bug report where someone had issues with prime + powerplay/dpm.  I
> can't remember what the GPU was though.
Perhaps my bug at https://bugs.freedesktop.org/show_bug.cgi?id=97075
tl;dr: If you're affected you get much better VCE performance by just running e.g.
vblank_mode=0 glxgears -info
in the background.