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

[Reimar Döffinger]

On 25 Sep 2012, at 00:42, Vladimir Mosgalin <mosgalin at VM10124.spb.edu> wrote:
> 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.

top should not count blocking as CPU usage, so you can't get 100% CPU that way (MPlayer status line will count it though, because it is not CPU usage but processing time / frame display time).

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

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.

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

Bigger differences should make it rather easier to analyze.

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