Announcement
Collapse
No announcement yet.
Video Acceleration Takes The Backseat On Chrome For Linux
Collapse
X
-
I use the opensource radeon stack on my HD 6870 and am a heavy Google Chrome user with the GPU blacklist disabled (to enable hardware acceleration where possible). Everything runs fine. Obviously video decoding is not accelerated, I am only talking about the general usage.
-
Originally posted by gradinaruvasile View PostYeah. My thoughts exactly. I have the latest OSS stack from git (A8-6500 apu, radeon/r600g driver) and Seamonkey and Firefox run webgl demos just fine and has accelerated playback (decoding too if enabled in the mms.cfg, but that seems to be limited to youtube, flash content on other sites crashes typically).
Chrome untiil quite recently worked just fine (albeit with generally higher CPU usage than Firefox/Seamonkey) if i disabled its blacklist, but recent versions crapped out, even SD flash video playback is crap and manages to use 200-300% CPU (i have 4 cores). This makes Chrome on Linux with OSS drivers (at least radeon) crap.
Summing it up, Chrome devs are just lazy - if Firefox could do it, what stops the best funded browser in the world (ok, ONE of them) from implementing it?
BTW Steam Source games run just perfectly fine on the radeon/OSS drivers.
Leave a comment:
-
Originally posted by shmerl View PostMozilla managed to do this with whitelisits. Not sure why Chrome team can not.
Chrome untiil quite recently worked just fine (albeit with generally higher CPU usage than Firefox/Seamonkey) if i disabled its blacklist, but recent versions crapped out, even SD flash video playback is crap and manages to use 200-300% CPU (i have 4 cores). This makes Chrome on Linux with OSS drivers (at least radeon) crap.
Summing it up, Chrome devs are just lazy - if Firefox could do it, what stops the best funded browser in the world (ok, ONE of them) from implementing it?
BTW Steam Source games run just perfectly fine on the radeon/OSS drivers.
- Likes 1
Leave a comment:
-
Originally posted by getaceres View PostOh yes, let's blame Google for being tired the mess which is the graphical stack of Linux nowadays. We have a graphic stack which was designed more than 30 years ago and to make it work with modern paradigms we patch it in every conceivable way. So taking apart DRI vs DRI2, XInput vs XInput2, Mesa vs Gallium3D, KMS and any other new patch above X limitations:
It comes Intel with EXA, UXA, GEM, SNA and God knows what else
Nvidia replacing half of the mess with their own private, closed and cryptic implementation
AMD doing the same on their part
Everyone has their own implementation of video acceleration and every one supports other features or not depending on their will and I'm ruling out legacy sytems and graphic stacks out of the main three. So now Adobe, Google or whatever other company tries to get hardware acceleration for their product of implement some other fancy feature easily implemented on the unified stack of Windows or OSX and they find bug after bug and it's normal.
And the situation is not improving. Wayland is taking ages to come out and still we have to see the support it might get from Nvidia and AMD, because without it, it's useless and in the mix comes Mir. Really?
So either Steam or Canonical or anyone else comes into play and gets enough traction to get companies on their side and cleans this mess in a dictatorship way or we continue as we go right now. Contrary to propietary systems we have freedom to implement what we want, but the price to pay is not having features implemented by third parties in a timely manner or implemented at all.
Anybody who has problems on Linux must have some turd hardware or software.
And Google has never been good at writing software. It's all third-rate, minimum-wage broken crap that looks like it was designed by a chimp on meth.
Leave a comment:
-
Oh yes, let's blame Google for being tired the mess which is the graphical stack of Linux nowadays. We have a graphic stack which was designed more than 30 years ago and to make it work with modern paradigms we patch it in every conceivable way. So taking apart DRI vs DRI2, XInput vs XInput2, Mesa vs Gallium3D, KMS and any other new patch above X limitations:
It comes Intel with EXA, UXA, GEM, SNA and God knows what else
Nvidia replacing half of the mess with their own private, closed and cryptic implementation
AMD doing the same on their part
Everyone has their own implementation of video acceleration and every one supports other features or not depending on their will and I'm ruling out legacy sytems and graphic stacks out of the main three. So now Adobe, Google or whatever other company tries to get hardware acceleration for their product of implement some other fancy feature easily implemented on the unified stack of Windows or OSX and they find bug after bug and it's normal.
And the situation is not improving. Wayland is taking ages to come out and still we have to see the support it might get from Nvidia and AMD, because without it, it's useless and in the mix comes Mir. Really?
So either Steam or Canonical or anyone else comes into play and gets enough traction to get companies on their side and cleans this mess in a dictatorship way or we continue as we go right now. Contrary to propietary systems we have freedom to implement what we want, but the price to pay is not having features implemented by third parties in a timely manner or implemented at all.
Leave a comment:
-
what to expect from a company that's even to lazy to support linux for their webdesigner...
Leave a comment:
-
Originally posted by brent View PostMeanwhile, Nvidia has been shipping a stable VDPAU implementation for many years, and the Mesa VDPAU implementation for Radeon and Nouveau graphics is shaping up nicely as well. Why does Google only care about Intel's proprietary VA-API?
They don't think that much on the low end GPUs that need it anyway.
Leave a comment:
-
We don't ship code we consider to be permanently 'experimental' or 'beta'
Leave a comment:
Leave a comment: