[MPlayer-dev-eng] [PATCH] A new ASS renderer
Vladimir Mosgalin
mosgalin at VM10124.spb.edu
Tue Sep 25 10:33:13 CEST 2012
Hi Reimar Döffinger!
On 2012.09.25 at 08:18:21 +0200, Reimar Döffinger wrote next:
> Well, at least it is the right way round. However that makes even less sense since it means that due to the higher speed gl processing should be done in the same time as vf_ass processing.
Well, it means difference is even more huge. After all, if I got very
big difference for non-karaoke 720x480 video, it probably is even worse
for karaoke full HD rendering.
> >>> Neither mplayer output nor perf seem to reflect how much mplayer was
> >>> lagging in gl-fullscreen-karaoke and glhack-fullscreen-karaoke modes,
> >>> with massive actual A-V difference due to sub rendering lagging so much.
> >>
> >> Hm, also run those tests with vsync disabled.
> >
> > According to driconf, I have vblank_mode at 0 (disabled, unless
> > application enables). So for this I use swapinterval=0 suboption for
> > vo_gl?
>
> Yes I think that should work. I'd feel a lot better if someone else could confirm this issue actually exists, because as I understand your description of the behaviour that should not be possible.
> Though maybe I should confirm my assumptions.
> When you say "100% CPU"
> 1) "top" shows something like 400% CPU for MPlayer (don't remember how many cores your CPU has).
> 2) "top" shows 100% active for each CPU core?
top shows numbers very similar to mplayer, few % more because it adds
CPU usage from different cores - there's "lavdopts = threads=4" option
active. So when mplayer shows "1% 34% 1.0%" top usually shows around
38-45%. In the worst test (gl rendering + fullscreen + karaoke), when
mplayer shows numbers 95-99%, top shows 115% at most - looks like all
the load from multithreaded h264 decoding + cache process + other stuff
done in threads just can't take more CPU than certain number, say, 15%,
and most consuming task (gl rendering) is single core-bound.
Though, top output kind of disagrees with the last part of what I just
wrote. It would be the case if there was some core stuck at 100% usage
without idle cycles, but in fact I never see *any* core under more than
40% load in any of these tests in top. For example, in said worst test
gl+fullscreen+karaoke (mplayer renders so slow it's lagging and reports
100% cpu usage by its own numbers) in top I see things like
top - 12:14:07 up 1 day, 13:41, 7 users, load average: 1.26, 0.38, 0.16
Tasks: 218 total, 2 running, 214 sleeping, 2 stopped, 0 zombie
Cpu0 : 28.1%us, 8.1%sy, 0.0%ni, 62.6%id, 0.0%wa, 0.4%hi, 0.7%si, 0.0%st
Cpu1 : 19.6%us, 6.3%sy, 0.0%ni, 72.6%id, 1.1%wa, 0.4%hi, 0.0%si, 0.0%st
Cpu2 : 34.9%us, 16.7%sy, 0.0%ni, 47.6%id, 0.4%wa, 0.4%hi, 0.0%si, 0.0%st
Cpu3 : 34.8%us, 5.6%sy, 0.0%ni, 59.3%id, 0.0%wa, 0.4%hi, 0.0%si, 0.0%st
Mem: 16402972k total, 16154632k used, 248340k free, 966956k buffers
Swap: 2097148k total, 0k used, 2097148k free, 10630396k cached
PID PPID USER TIME+ RES SHR VIRT PR NI S P %CPU %MEM COMMAND
30611 3233 mosgalin 0:46.01 743m 78m 10.0g 20 0 R 3 115.1 4.6 en-mplayer-glha
2696 2539 mosgalin 73:27.03 395m 41m 1932m 20 0 S 1 14.8 2.5 gnome-shell
2452 2450 root 130:01.85 152m 13m 360m 20 0 S 0 8.1 1.0 Xorg
3227 1 mosgalin 9:03.92 29m 13m 719m 20 0 S 1 5.9 0.2 gnome-terminal
30391 2 root 0:01.64 0 0 0 20 0 S 0 2.6 0.0 kworker/0:0
30608 2 root 0:00.79 0 0 0 20 0 S 2 2.2 0.0 kworker/2:2
Version without hack behaves the same
top - 12:18:34 up 1 day, 13:45, 7 users, load average: 0.43, 0.36, 0.21
Tasks: 216 total, 2 running, 212 sleeping, 2 stopped, 0 zombie
Cpu0 : 18.6%us, 7.3%sy, 0.0%ni, 73.4%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st
Cpu1 : 22.0%us, 6.7%sy, 0.0%ni, 71.0%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st
Cpu2 : 37.2%us, 16.1%sy, 0.0%ni, 46.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 26.0%us, 8.7%sy, 0.0%ni, 64.7%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st
Mem: 16402972k total, 15594976k used, 807996k free, 967324k buffers
Swap: 2097148k total, 0k used, 2097148k free, 10573056k cached
PID PPID USER TIME+ RES SHR VIRT PR NI S P %CPU %MEM COMMAND
30619 3233 mosgalin 0:17.59 231m 44m 1072m 20 0 S 0 114.7 1.4 en-mplayer
2696 2539 mosgalin 73:50.99 395m 41m 1931m 20 0 S 2 13.0 2.5 gnome-shell
3227 1 mosgalin 9:08.52 29m 13m 719m 20 0 S 0 3.3 0.2 gnome-terminal
2452 2450 root 130:08.82 152m 13m 360m 20 0 S 3 3.0 1.0 Xorg
30391 2 root 0:02.06 0 0 0 20 0 S 0 2.7 0.0 kworker/0:0
30360 2 root 0:00.07 0 0 0 20 0 S 3 2.3 0.0 kworker/3:2
30406 2 root 0:00.78 0 0 0 20 0 S 1 1.7 0.0 kworker/1:0
Tons of idle time for each core. Go figure..
If I turn off multithreaded decoding (threads=1) then I get different
picture: in same test in mplayer I see
A: 20.1 V: 20.1 A-V: -0.000 ct: 0.075 0/ 0 39% 113% 1.6% 85 0 65%
(CPU usage numbers shown in mplayer are always around 15-20% more in
single thread mode even when no subtitles are rendered)
and during that in top
top - 12:30:05 up 1 day, 13:57, 7 users, load average: 0.58, 0.37, 0.26
Tasks: 218 total, 3 running, 213 sleeping, 2 stopped, 0 zombie
Cpu0 : 9.5%us, 9.5%sy, 0.0%ni, 81.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 20.0%us, 5.0%sy, 0.0%ni, 75.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 50.0%us, 10.0%sy, 0.0%ni, 40.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 4.8%us, 9.5%sy, 0.0%ni, 85.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16402972k total, 15633052k used, 769920k free, 968832k buffers
Swap: 2097148k total, 0k used, 2097148k free, 10608900k cached
PID PPID USER TIME+ RES SHR VIRT PR NI S P %CPU %MEM COMMAND
30679 3233 mosgalin 0:09.89 145m 40m 733m 20 0 R 2 82.7 0.9 en-mplayer
2696 2539 mosgalin 75:02.09 395m 41m 1932m 20 0 R 1 9.7 2.5 gnome-shell
3227 1 mosgalin 9:15.68 29m 13m 719m 20 0 S 3 9.7 0.2 gnome-terminal
2452 2450 root 130:38.29 152m 13m 360m 20 0 S 3 4.9 1.0 Xorg
3131 2565 mosgalin 3:10.40 5496 2256 426m 20 0 S 0 4.9 0.0 ibus-daemon
30360 2 root 0:01.29 0 0 0 20 0 S 3 4.9 0.0 kworker/3:2
30678 2 root 0:00.67 0 0 0 20 0 S 0 4.9 0.0 kworker/0:2
I'll redo these tests after disabling powersaving modes, overclocking
and turbo boost this evening.
--
Vladimir
More information about the MPlayer-dev-eng
mailing list