[Bug 55913] Vdpau driver lag

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 1625 bytes --]

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

--- Comment #5 from Andy Furniss <lists@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.

[-- Attachment #1.2: Type: text/html, Size: 2442 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel