reminding of this (xkcd)
this patchset might be the missing puzzle-piece for "smooth full-screen flash video"
I haven't tested full-screen flash yet
another important part is that Adobe implements video-acceleration
perhaps the easiest would be to use openGL ES 2.0 ? (I don't know if that even would work)
ok, HD video seems to work fine (beautifully), too
in fullscreen with new catalyst 10.8 and almost no GPU load
try the following video *click*
make sure you select 720p
you might need to force hardware acceleration:
Originally Posted by /etc/adobe/mms.cfg
Smooth full-screen Flash video works here just fine with open display drivers on an ATi card. Just takes 32bit Adobe Flash on a 32bit Firefox.
Originally Posted by kernelOfTruth
ps. Fine, that video takes a lot of CPU in 720p but not enough to use even a single full core on E8500 and definitely not enough to make it kick the CPU fan on more rotations.
That video works perfectly fine and fluid in 720p fullscreen here with open source radeon driver and BFS scheduler :P
What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?
I don't know about this patchset in particular, but frequently, responsiveness issues are a direct tradeoff with throughput and efficiency. The efficiency side: For better responsiveness, the CPU has to be awake a lot, constantly processing events to make things "respond" as quickly as possible. The throughput side: Aside from scheduler thrashing issues that may interfere with processes' ability to get a consistent stream of work done, the other problem with most responsiveness patches is that it creates a lot of overhead in terms of context switches, cache flushes, and IPIs. This can reduce the amount of operations per second that can be performed on the CPU.
So for servers, you want to line up as many bowling pins as you can, and then bowl a strike, even if it takes you time to line them up. For desktops, you want to throw down one pin, sprint back, grab the bowling ball, hit that one pin, and repeat. Although you can probably set up and hit one pin faster than you can set up 12 or 24 pins and hit them, you've hit less pins in that time than you could have. Hence the throughput vs responsiveness issue.
I've seen a great many VFS, virtual memory/allocator, and scheduler patches hit mainline in the past year, and sometimes I worry that it's just some guy with a hammer trying to find something that looks like a nail. Phoronix has noted that most kernel releases bring only regressions for typical systems, not improvements. How long have we been sliding down the performance slope, and how far will we keep sliding until everyone is happy?
I'm all for configurability, though. If there's a patch that has a tradeoff, merge it to mainline and add a config option. We could always use more config options. It warms the Gentoo user's heart, and for the rest of us, it gives the distro kernel maintainers something useful to do, like set the proper options for the desktop vs. server kernels.
So in closing, if this patch is universally either beneficial or a wash regardless of whether you're in a desktop or server environment, I say merge it without an option. But if we find that it comes with added overhead and reduced throughput for servers, it shouldn't be merged unless it can be made configurable, at least with a Y/N if a module doesn't make sense.
It seems no one pays attention. These patches were introduced in order to improve performance on server load. Linus Torvalds complained that it damaged desktop performance. So this is round two of those patches: improving server performance while not hurting desktop performance.
Originally Posted by allquixotic
I don't get why everyone, including Michael, claims these are desktop improvement patches in the first place. Which is why I don't trust this whole thing, since I care only about desktop issues... Too much misinformation and no real explanation at what these patches do.
The problem are graphic drivers and/or related things. Others are probably nearly meaningless compared to causes of 'slowness' related to graphic.
Originally Posted by unimatrix
The same here, but with 32bit flash and 64bit Firefox. Top shows CPU load 110% (Athlon X2 5000+), kwin compositions enabled, 2.6.32 kernel and git version of open source radeon driver from Ubuntu ppa.
Originally Posted by nanonyme