[Bug 55913] Vdpau driver lag
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Oct 23 04:42:57 PDT 2012
https://bugs.freedesktop.org/show_bug.cgi?id=55913
--- Comment #5 from Andy Furniss <lists at andyfurniss.entadsl.com> ---
(In reply to comment #4)
> mplayer2 uses advanced VDPAU functionality that mplayer does not use - the
> presentation queue. This works fine with Nvidia's implementation. Likely the
> bug is in Mesa's implementation of the presentation queue.
Maybe, but maybe it's something as simple as the fact (or way) that mesa vdpau
is vsynced.
Some further testing results -
Use VDPAU_TRACE=1 and grep/awk/bash to get the diffs from the timestamps
mplayer2 uses on vdp_presentation_queue_display.
Playing 25 fps on a 60Hz screen looks OK ish for a while -
50030334
33349000
50022000
33350000
50022000
33348000
50023000
33349000
50022000
33349000
33356334
33333332
50029334
but then when it starts lagging mplayer2 is asking for longer intervals -
100052334
16682334
100046000
16673000
100046000
16674000
83333330
66728336
83371000
66697000
83372000
66697000
83370000
66699000
83370000
First thought it's trying to framedrop - maybe my GPU is too slow (it's
powerful but set to low).
Turn it up and no lag - me thinks that's it then, but then mplayer works so
another test.
GPU on low again but screen @120Hz also = no lag, so it's not just perf.
If you know mplayer2 code well perhaps that will tell yoou something.
Another separate observation SD or HD just -vo seems to work but the %cpu shown
for vo rises. It seems it's rate of rise decreased as it gets higher so I don't
know if it will ever get to 100 and start lagging.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121023/fed7aac1/attachment.html>
More information about the dri-devel
mailing list