BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 10:00 UTC (Mon) by tialaramex (subscriber, #21167)
In reply to: BFS vs. mainline scheduler benchmarks and measurements by DavidG
Parent article: BFS vs. mainline scheduler benchmarks and measurements

Wrong part of the kernel. You want KMS / DRM, specifically screen flipping (to get all the changes from a frame onto the screen at the same time, and ensure that time isn't while the screen is being drawn)

But mostly you want high level graphics drivers (to accelerate video playback) and a decent Flash player (either from Adobe or reverse engineered by Gnash etc.) which aren't in the kernel at all.

to post comments

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 10:39 UTC (Mon) by DavidG (guest, #60628) [Link]

I was referring to the same XKCD comic (http://xkcd.com/619/) that encouraged Con to do this, but no the scheduler plays a big role as well, with the greatest drivers and GPU you'd otherwise still end up with glitches in the sound and dropped frames in your video player.

I'd suggest two new benchmarks:
- One with basically an Ogg player playing music and a sound capture application that scans the stream for glitches and transfers the amount of glitches to some sort of benchmarking number,
- a benchmark that detects dropped frames and sound glitches when playing video's and transfers that to some sort of benchmarking result.

And all under some sort of heavy load (e.g. make kernel, cpuburn) Perhaps these tests are already available, but I could not find tests that are design to do this specifically under heavy load...

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 12:05 UTC (Mon) by ldarby (guest, #41318) [Link] (7 responses)

Going slightly off topic, mplayer has always been able to play flv's smoothly, so I don't see how you can call Adobe's flash player "decent", it constantly pegs the cpu at 100%, doing nothing more than mplayer which uses 0-5%.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 14:41 UTC (Mon) by cortana (subscriber, #24596) [Link] (2 responses)

FYI, the reason Flash is so godawfully crap at playing video is because it actually *does* have to do a lot more than mplayer.

All mplayer has to do is decode video to YUV and then hand the picture off to the video card, which scales it to fit the screen, etc, in hardware.

Flash has to decode the video, then convert it to RGB, then combine it with other graphical elements created on the fly by a flash movie written by someone who has no idea how to program efficiently, then somehow get the result to the screen, and the methods for doing this for RGB data on Linux are buggy, inefficient, and hardware-dependent (when they even exist in the first place!)

Having said that, there is a great deal of room for improvement on the Flash side as well. One of the people who works for Adobe in porting the Flash player to Linux--a thankless task!--occasionally posts to a blog where he details interesting problems he runs into. Some interesting posts include:

http://blogs.adobe.com/penguin.swf/2008/05/
http://blogs.adobe.com/penguin.swf/2006/10/
http://blogs.adobe.com/penguin.swf/2006/09/#a001737

and another that I can't find right now where he writes about how the Windows version is accelerated by assembly code which has been optimised for years, but the Linux version can't because it's all locked away in Microsoft's assembler source format or something.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 15:30 UTC (Mon) by Cato (guest, #7643) [Link] (1 responses)

That point about the Microsoft assembler format is curious - surely it wouldn't be that hard to translate that format to GNU's? A small investment of time and a massive return if Adobe were to then use accelerated assembly code for Flash...

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 16:38 UTC (Mon) by cortana (subscriber, #24596) [Link]

Found it!

http://www.kaourantin.net/2005/08/porting-flash-player-to...

Now, the 'see this post for updated info' does say that this information is outdated, and that version 9 of the Flash Player on Linux is much faster than previous versions (which it was).

I still think there's huge room for improvement. But I understand that, while the Windows Flash Player developers spend time on optimizing, the Linux porters have to spend time making it work on a much wider variety of environments and with different versions of different libraries and graphics drivers and dealing with bugs in all of the above that are fixed in newer versions that end-users can't install because their distribution hasn't been updated for over a year, etc. etc.

For instance, I Flash won't bother to use the GPU on my Intel based laptop to accelerate rendering because:

$ glxinfo | grep 'client glx vendor'
client glx vendor string: SGI

and 'SGI' implies 'software rendering', which of course isn't true on my Intel-equipped laptop, but apparently when the developers tried to use a better method it would cause crashes on some distributions...

Details at <http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the...>.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 15:58 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

Flash works in RGB space, whereas mplayer has the luxury of not needing to composite UI on top of the video and so can just dump YUV data into the hardware scaling engine. That's where most of the performance difference comes from.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 20:11 UTC (Mon) by alankila (guest, #47141) [Link] (2 responses)

Linux with its texture-from-pixmap extension should be able to support RGB scaling via hardware, only I spent a few days last summer trying to get this feature to work---and after failing that, just getting some demos that should use this feature to work. That failed too. But: compiz works just fine, so the extension is probably okay. The X errors which I received were just so undebugable that I just gave up trying to figure out what is wrong.

Once Linux, too, can take RGB surface and display it on screen with hardware acceleration, things will indeed be better for us. But here's me wishing: it should be easy, not just "maybe works if you happen to have the right mixture of everything installed and moon's phase is just right".

It's awful how Linux slowly conditions one to inferior experience. I had a friend visiting and he was genuinely surprised when he saw that I could press the full-screen button on youtube and it actually worked. He failed to notice that at that time I was actually running Firefox within Windows... ;-(

From end-user point of view, this problem can't die fast enough.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 8, 2009 11:58 UTC (Tue) by nye (subscriber, #51576) [Link] (1 responses)

> I had a friend visiting and he was genuinely surprised when he saw that I could press the full-screen button on youtube and it actually worked

I agree that performance isn't brilliant - in particular, the YouTube Flash applet becomes absurdly slow in full-screen when the controls are visible, though some other applets don't have that problem - but I'd be surprised if full-screen Flash video didn't work at all. In what way does it fail for you/him?

*My* problem with Flash is that Firefox appears to be aggressively single-threaded, and a few times a minute decides to peg the CPU for a second or so, so if I want to play Flash smoothly I have to use Opera - or Konqeror, or any non-Firefox browser really.

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 8, 2009 23:59 UTC (Tue) by alankila (guest, #47141) [Link]

Well, what I get is that the full-screen button flashes a full-screen video for a frame or two, and invariably falls back to windowed mode. I'm not sure if that is the symptom for him, though.

It could also be another problem: right now mouse button clicks within the flash applets don't seem to register -- I have to start video playback by pressing space because clicking with the mouse somehow doesn't seem to go through. Especially pressing the full-screen button does absolutely nothing right now. *sigh*