User: Password:
|
|
Subscribe / Log in / New account

Quotes of the week

Documentation is the sort of thing that will never be great unless someone from outside contributes it (since the developers can never remember which parts are hard to understand).
Avery Pennarun

I have an interesting problem: How do I shoehorn "hired by The Internet for a full year to work on Free Software" into my resume?
Joey Hess
(Log in to post comments)

Quotes of the week

Posted Jun 22, 2012 1:50 UTC (Fri) by AndreE (guest, #60148) [Link]

Nice to see a successful free software project on Kickstarter.

What I'd love to see is a project targeting the radeon and noveau drivers.

Quotes of the week

Posted Jun 22, 2012 8:44 UTC (Fri) by nix (subscriber, #2304) [Link]

People are *already* paid to work on the radeon drivers. Though I'm sure more effort would not go amiss, how many Linux X driver or DRM hackers are there who know how the radeon hardware works in sufficient detail, aren't already paid to work on it, and haven't got enough spare time to work on it? Plus, radeon support is fairly complete now, excepting only GPU computation and accelerated video decoding support.

More necessary I think is work on Mesa itself: it routinely comes out of benchmarks half an order of magnitude or so slower than the proprietary competition, which is unfortunate. (But maybe Gallium fixes this? I don't know. Also half those benchmarks are Phoronix benchmarks so take them with an entire ocean-full of salt.)

Quotes of the week

Posted Jun 23, 2012 3:52 UTC (Sat) by nickbp (guest, #63605) [Link]

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.

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 (guest, #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 (guest, #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.

Quotes of the week

Posted Jun 28, 2012 18:16 UTC (Thu) by bustervill (guest, #85383) [Link]

I don't know what do you mean. The radeon driver support is not nearly complete. Yes, most major features are there, but the performance is an endless void nobody has dived into yet. There is no TGSI compiler whatsoever. The developers are fiddling with LLVM for an OpenCL support and people are wondering if reusing LLVM as TGSI compiler will be worth it. That of course will mean _another_ translation of the IR - from TGSI to LLVM IR. Also, LLVM is slooow when it comes to JIT. It's optimization passes are effective, but expensive. It cannot be used to JIT something that relies on low latency as a 3D driver.
TGSI compiler is one of the projects that has to be explicitly funded in order to launch. Until then, there will only be the interpreter delivering sub-par performance and maybe (just maybe) a (also slow) LLVM integration side project.

Quotes of the week

Posted Jun 29, 2012 7:09 UTC (Fri) by daenzer (✭ supporter ✭, #7050) [Link]

> The developers are fiddling with LLVM for an OpenCL support and people are wondering if reusing LLVM as TGSI compiler will be worth it.

No need to wonder anymore, just build Mesa with --enable-r600-llvm-compiler. It seems to be more or less on par with the non-LLVM TGSI translator in general already.

> That of course will mean _another_ translation of the IR - from TGSI to LLVM IR.

Initially, sure. Not sure it's that much of a problem, and it doesn't have to stay that way forever.

> Also, LLVM is slooow when it comes to JIT. It's optimization passes are effective, but expensive. It cannot be used to JIT something that relies on low latency as a 3D driver.

Again, not sure it's as bad as you make it, and if it is, there's many possibilities to address that.

> TGSI compiler is one of the projects that has to be explicitly funded in order to launch.

Tom Stellard's OpenCL / LLVM compiler work is funded by AMD. But as you call what we're doing 'fiddling', maybe you can volunteer to show us how it's done? Please post to the mesa-dev mailing list. :)

Coda to Avery's Observation

Posted Jun 23, 2012 1:59 UTC (Sat) by maney (subscriber, #12630) [Link]

Those outside don't understand the hard parts well enough to document them, of course. If they learn them well enough, then they at least start to suffer from the same problem the developers have. It really takes a rare partnership to create great docs.


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds