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

[Vladimir Mosgalin]

Hi Reimar Döffinger!

 On 2012.09.24 at 23:22:34 +0200, Reimar Döffinger wrote next:

> On Tue, Sep 25, 2012 at 12:31:42AM +0400, Vladimir Mosgalin wrote:
> > perf record/report output seems mostly meaningless, though. For example
> > ass-fullscreen-karaoke vs ass-window-karaoke tests - big difference in
> > CPU usage but same perf output.
> 
> The perf output says rather clearly that MPlayer in both cases uses
> 330K CPU cycles.
> I see very few possible explanations and none of them make sense
> 1) Your CPU executes vastly fewer cycles per second in the fullscreen
> case
> 2) Vastly more CPU time is spent outside MPlayer in fullscreen mode.
> This is quite an issue since a process being able to cause a huge
> additional CPU usage that is not accounted to it is a rather nice DoS
> tool.

(just an assumption) it might be possible if something is done
asynchronously in drm module in kernel. For example: Mesa does
something through drm interface, drm in kernel says "ok, it'll be done"
and returns. Then it does that in background (we get CPU usage in kernel
here, but unrelated to original application) and if Mesa asks to do
something else it blocks "wait till I finish previous task". This
blocking is considered to be CPU usage for mplayer, but perf is more
smart and doesn't account it to usage.

I'm not really sure it works like this :) Just, if I had to assume
something about unknown system, I'd have such idea.

Anyhow in this case perf record in system-wide mode can provide more
results here...

> Have you run all these tests with the CPU forced to some fixed
> frequency? I'm not keen on ending up debugging TurboBoost issues for
> example.

No :(
CPU frequency floats from 1.6Ghz in idle to 4.5Ghz, separately for each
core. In these tests it was around 2-2.4Ghz for tests that used "-vf
ass" and around 3Ghz for vo_gl rendering + windowed mode and at top
frequency (4.5) for fullscreen for "most active" core.

Locking it, well, is kind of complicated on my motherboard. It can't
overclock if I disable turbo boost, or can't do turbo boost if I disable
powersaving modes. So if I try to lock, it'll be stuck on base frequency
(3.3 Ghz), can't make it higher. This is much slower than current max
speed so vo_gl rendering + fullscreen test is going to get much worse
results..

If this is fine, I can try to change settings and repeat tests tomorrow.
Please tell me if you need anything else changed and if I should try to
do system-wide "perf record" collection.

> > Or "isolate_freepages_block" which
> > appears only in glhack version (that's with your patch), but strangely
> > taking way more CPU usage in window.
> 
> As you can see from the EOSD stats printout the windowed mode behaves
> significantly different. In particular, the modified code is used
> only very little in fullscreen mode, since most glyphs are larger
> that 64x64 pixels (which I do not understand at all, almost all
> are smaller that 64x64 for me with the same screen resolution -
> my best guess is that I do not have the right/same fonts installed as
> you).

You can check subtitle file that I added, it uses special fonts.
Actually if you can download torrent, you can check original file, it
has embedded fonts.
It's [Doki] Air - NCOP (A) (1920x1080 h264 BD FLAC) [2EA65F7C].mkv
from this torrent
http://tracker.anime-index.org/index.php?page=torrents&search=Doki+Air+h264+720&active=0

> > 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?

-- 

Vladimir