| |||||||||||||
Quotes of the weekQuotes of the weekPosted Jun 23, 2012 3:52 UTC (Sat) by nickbp (subscriber, #63605)In reply to: Quotes of the week by nix Parent article: Quotes of the week
AMD has recently dropped fglrx support for my 3.5-year-old 4850. Meanwhile, Debian testing has updated xorg to version 1.12, which the last-available fglrx apparently does not support. This has resulted in fglrx being dropped* from Debian testing, with Gallium functioning as its replacement. The resulting drop in performance has made XBMC suddenly become near unusable** on my HTPC machine. This would imply that Gallium still has quite a ways to go before it can be considered a true drop-in replacement for its proprietary counterpart.
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671320
** Regularly dropped frames in any video, horrible fps (~5 or thereabouts) when merely navigating the normal menus with the Aeon theme.
PS: I personally blame ATI for their ridiculously short support lifetime, and intend to never buy another AMD product in the foreseeable future due to the unnecessary hassle their lack of support has caused. Indeed, I am considering buying a new NVidia card to resolve the issue which AMD has created.
(Log in to post comments)
Quotes of the week Posted Jun 23, 2012 10:37 UTC (Sat) by daenzer (✭ supporter ✭, #7050) [Link]
> Regularly dropped frames in any video, horrible fps (~5 or thereabouts) when merely navigating the normal menus with the Aeon theme.
That sounds like something's wrong. If you've verified it's really using hardware acceleration, it might be worth reporting a bug with the full Xorg.0.log file and the output of dmesg and glxinfo.
Quotes of the week Posted Jun 23, 2012 14:15 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
OpenSource ATI drivers for old chips are roughly comparable in performance with fglrx. So if you get a massive drop in FPS it might be happening because you're using software rendering.
Especially since you were using fglrx before. Fglrx tends to leave its bits behind.
Quotes of the week Posted Jun 29, 2012 7:14 UTC (Fri) by elanthis (guest, #6227) [Link]
The FOSS AMD drivers for the r300-r500 chips (the r300 driver) have great performance often comparable to fglrx. The HD 4000 series is the r700 family (the r600g driver) which is still severely lacking in performance compared to the proprietary drivers.
Quotes of the week Posted Jun 28, 2012 20:40 UTC (Thu) by Tuna-Fish (subscriber, #61751) [Link]
This is definitely not normal behaviour for 4850 and gallium. It's not a speed monster, but it should do simple video and ui without a hitch. Try reinstalling your display stack?
Quotes of the week Posted Jun 28, 2012 22:26 UTC (Thu) by nickbp (subscriber, #63605) [Link]
I'd actually just figured out the problem just last night when debugging other unrelated issues* from a more recent Xorg update. Turns out Debian/wheezy had refrained from installing a firmware blob which was a prerequisite for hardware acceleration. There was a convenient message stating this in Xorg.*.log, which I'd not thought of checking until debugging the new update's unrelated issues.
After installing 'linux-firmware-nonfree', things were suddenly much speedier -- I could no longer see any subjective difference between radeon vs fglrx where video playback/xbmc were concerned. Not clear why linux-firmware-nonfree wouldn't be installed by default given a system configuration that needs it, but I guess that's more of a political issue.
* Something was causing Xorg to fill /var/log with hundreds of Xorg.*.log's. Wiping xorg.conf fixed whatever it was
Quotes of the week Posted Jun 29, 2012 22:30 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] Not clear why linux-firmware-nonfree wouldn't be installed by default given a system configuration that needs it, but I guess that's more of a political issue. Yes, Debian policy does not allow packages in the main section (Debian proper) to recommend non-free packages. The linux-image packages do try to warn during an upgrade if you're using a driver and don't have the corresponding firmware, though they won't catch all cases. We could maybe try to make the run-time errors more obvious.
|
|||||||||||||