How does AMD/ATi fglrx beta driver testing work?
I am just curious if there is someone here which could share some insight into the driver beta testing process that AMD/ATi is running before releasing a new fglrx driver. I guess some of this info is under NDA, but perhaps at least a little info could be shared.
Lately, we've had some new outstanding bugs in the driver, such as the infamous OpenGL memory leak (in e.g. 7.11) or dropped support for many wide screen resolutions (in 7.12), making many people wonder how the beta testing process works and why it does not catch such problems.
We are masters in creating our own FUD around here due to lack of information and insight into the development process, and a little more info could perhaps lower the "temperature" in the forum a bit.
So, for instance:
How many AMD developers work on the fglrx driver? How wide range of hardware is tested in-house before each release? What software is generally used by the devs for testing?
How many non-AMD Linux developers and users have access to binary beta releases? What hardware is covered? What software are they encouraged to try? How does bug reporting work? How can one become a tester?
Yes, some on-going communication from ATI/AMD would help
Amen to that!
On a personal note, I am wondering why none of the fglrx drivers released since version 8.42 onwards work properly on my shiny new HIS Radeon HD2600XT IceQ turbo AGP?
I have to disable DRI to make the driver work which totally defeats the purpose!
Aside from that, none of the catalyst 7-10 & later windows installers (I have a dual-boot PC) recognise the card under windows either, forcing me to manually install them after which they work properly.
I guess some insight into how ATI works together with OEMs to incorporate all the different versions of their cards / chipsets into the driver would also help?
Thanks for the hint Oliver, I had already found that thread. It's very helpful of you to point it out, thanks again.
Originally Posted by oliver
First off, I couldn't find that error in my Xorg at all, so I think my AGP card is getting a proper interrupt.
Second, I'm not sure if the HD2600XT uses the Rialto bridge chip? Does anyone know?
Third, I´ve tried every fglrx driver that came out since the HD2600XT AGP was released & supported, they all behave differently but none work with DRI enabled.
They work okay with DRI off though, so I doubt it's a hardware issue?
At any rate, I've tried Catalyst 7-12 as well, with every AGP aperture BIOS setting available to me, and I simply can't get that driver to work with DRI on.
Best result I've had so far with DRI on was the 7-11 version which came to the point of drawing the Ubuntu 7.10 greeter screen and getting stuck just beyond the point of drawing the first "Ok" button filling the rest of the screen with white before hanging up my PC.
All other drivers result in a black screen and a hung PC right after starting GDM.
I think my issue is different, though likely related to dodgy AGP support in the fglrx drivers, and at any rate, it seems as if the AGP issues reported in that thread aren't fully resolved in 7-12 anyway.
These question sound like "come on, does AMD know about its driver issues?". The answer is yes.
You're partially right.
Originally Posted by d2kx
The questions also speak "AMD/ATI, we assume you're doing something to fix these driver issues but please acknowledge & confirm that you are?"
I have seen many threads on this forum, both before and after I registered, that indicate whatever is coming up in the next Catalyst fglrx release is a big mystery to everyone here, in other words, "pot luck" depending on which ATI chipset / card one has in one's system.
The release mechanism of ATI and the various driver branches for Linux that have been out there have now been properly explained by a kind person "in the know" but I think 'engaging with the open source community' ought to go further than slowly opening up the engineering specifications of the different chipsets.
I believe ATI, now AMD, could become a greater supporter of the open source community with relatively little effort by opening up a communication channel (a "Blog", perchance) to us that lets us know what's going on. A bit like what Adobe did when they were working on flash 9 for Linux, if you were following that.
I believe that would buy them tons of goodwill that could stem the flow of ATI users to nVidia for lack of proper driver support from ATI for their platform of choice.
EDIT / UPDATE: woops, bridgman's post indicated that what I suggest here is possibly already happening.
I hadn't read that one when I posted my reply (and I believe bridgman was "the kind person in the know" to begin with as well :-$ )
Last edited by Swoopy; 12-28-2007 at 12:52 PM.
We are going to do that in the new year, but in the early days our focus was on supporting the radeonhd development team at Novell/SuSE. We have weekly calls with them and work through lists of open questions and issues, although it's only recently (since Alex joined us) that we have been able to generally keep up with their questions.
Originally Posted by Swoopy
FYI, I think the "kind person" who provided info on the fglrx release cycle was actually Matthew -- I only became involved in the Linux side when we started the recent open source initiative. Our Linux development cycle was mid-way through a major transition when that article was written so it's probably time for an update. I think the Q&A will probably answer most of the questions.
Last edited by bridgman; 12-28-2007 at 02:41 PM.
Bridgman, are you a developer of ATI/AMD linux driver team? If the case, I hope you would look back R3xx Users who were left behind the support of fglrx. I use mobility radeon 9600 on my ThinkPad T42, and with fglrx it DOES NOT suspend, wake up. With AIGLX on, Compiz works but average responsiveness of all app is totally unusable(eg, firefox scrolling, multi-tasking...).
Originally Posted by bridgman
I really really hope these BASIC issues would be fixed soon.
You deserve the title of "kind person" yourself as well with that thorough response.
Originally Posted by bridgman
ok, but do they know about them from their beta testers, _before_ users discover them? or is it the other way around and the users are unwilling beta testers this time?
i sometimes have serious doubts about that, because if they had found most serious bugs in beta tests they would put them into release notes (which would get 3 times as long in result).