[MPlayer-dev-eng] [PATCH] A new ASS renderer

[Vladimir Mosgalin]

Hi Reimar Döffinger!

 On 2012.09.25 at 20:03:53 +0200, Reimar Döffinger wrote next:

> On Tue, Sep 25, 2012 at 12:33:13PM +0400, Vladimir Mosgalin wrote:
> > I'll redo these tests after disabling powersaving modes, overclocking
> > and turbo boost this evening.
> 
> The "top" numbers might be easier to interpret after setting CPU
> affinity so that MPlayer will only use one CPU.
> Though that might require using a video that is a bit easier
> to decode.

Okay, the new numbers are here:
http://178.130.36.83/perf-reports-all-v2.tar.gz

All CPU cores were locked on 3.3 Ghz this time.

Overall: not much difference. -vf ass is way faster than -vo gl,
"hacked" gl driver is faster than original but still not fast enough for
fullscreen rendering to be done in realtime; you can see in mplayer.out
that mplayer execution time was longer than 153 seconds - in this case
158.76 means 5.7 seconds of accumulated lag. Of course, still much
better than original gl version with 178 seconds total or 25 seconds of
lag (it was visibly much slower than when CPU was at 4.5 Ghz in same
test).

-vf ass + window is quite a bit faster than -vf ass + fullscreen,
according to mplayer numbers. No difference in perf output at all. I
did system-wide perf collecting (just for the time mplayer was running)
for this and many other tests too, with "sudo perf record -a", but I
don't think there is much difference there either (but maybe you'll spot
something).

Now interesting thing is that I don't see any difference for mplayer's
usage in top for these two modes. Also, if I use "-lavdopts threads=1"
and lock mplayer to single cpu with tasksel, I see mplayer's output like

A:  34.8 V:  34.8 A-V:  0.000 ct:  0.075   0/  0 31% 12%  0.6% 0 0 51%

for windowed mode and like

A:  28.8 V:  28.8 A-V:  0.001 ct:  0.075   0/  0 32% 36%  0.6% 0 0 56%

for fullscreen mode.

Note that "usual" multithreaded decoding + fullscreen mode produces like
like

A:  21.0 V:  21.0 A-V:  0.000 ct:  0.075   0/  0  1% 31%  0.7% 0 0 68% 

In other words, what mplayer prints about CPU usage seems to be quite
questionable, its way of calculating where exactly CPU is used seems to
be unreliable if multiple cores are used.


I tried disabling vsync with swapinterval=0 suboption for two tests;
can't spot any difference in performance. Unfortunately, I can't say if
vsync was enabled or disabled in these tests by eye, I'm usually not
sensitive to this except for most extreme cases..
What I find a bit strange, though, that even with -msglevel vo=7 gl
driver never wrote if it tried to enable or disable vsync, output seems
to be the same in all modes?

Anyhow at least CPU usage between window and fullscreen vo_gl rendering
shows big difference and perf output seems to completely match it; can
you make something out of it?

This (slow fullscreen) is much worse problem than karaoke rendering.
At least karaoke problem seems to be mostly solved by gl hack. It's now
only about 33% slower than -vf ass rendering (when comparing perf output
between ass-window-karaoke and glhack-window-karaoke).

A silly question: is it possible/desirable to further increase numbers
increased by glhack patch? Like, use 4096x4096 textures and increase small
texture size.


-- 

Vladimir