08-20-2008, 09:45 PM
On the fglrx side, we started the transition to common code a few years ago, even before joining up with AMD. The primary goal was to better address the workstation business but the work also made it possible to start bringing high-end features and performance to consumer users.
On the open source side, a couple of things happened at the same time. As a result of joining up with AMD we picked up an additional set of customers (buying CPUs rather than GPUs) and those customers generally had a significant interest in out-of-the-box Linux support. AMD CPUs have been strong in the server space for a while but those same customers are also targeting enterprise client users with Linux and so open source driver support for our GPUs was identified as a top priority for a number of the larger CPU buyers.
To a certain extent open source GPU driver support is a "cost of doing business" on the CPU side, but it benefits both enterprise and consumer users in the process.
There have been super-charismatic Linux advocates on both the ATI and AMD side for a while, but until the last couple of years it was tough to provide any business justification for investing in Linux support. We are probably still spending more on Linux support than the market share today justifies, but I think we can justify the investment with the potential of greater workstation and enterprise client sales in the future.
Last edited by bridgman; 08-20-2008 at 09:48 PM.
08-20-2008, 09:46 PM
I have been on vacation and largely "off the grid" for the last couple of weeks, but will ask around on Monday when I get back in the office.
Originally Posted by mitch074
08-20-2008, 11:02 PM
My question regards the "resolved issues" and "known issues" sections in the release notes.
From looking at these sections for the last 10 or so fglrx releases, it seems to me that it represents only problems discovered by QA folks through limited tests, using scenarios not very common (or, indeed, important) for the average user. See, for example, the resolved issue on last release concerning flashes upon launching Catalyst control centre on a CRT screen attached to a X1600. The main issues, stirring the community up (like the infamous WINE checkerboard of doom), fail to appear at the list of known issues, and when (and if) they are fixed it is a sort of nice surprise mixed with a sigh of relief.
Is it possible to fortify the connection between your bug fixing priorities, as affected by both QA and users reports, and your release notes? It seems to me that some parts in the release notes represent a legacy of community-ignoring beurocracy, which actually no longer dominates the AMD linux team. Currently the main communication channel of the community to you is through this website; I believe everybody will feel better if the official messages of AMD to its linux users, i.e. driver release notes, will also reflect a recognition of the community's problems and needs.
08-20-2008, 11:18 PM
Another name for the "community-ignoring bureaucracy" is "the workstation market", which *does* still dominate the AMD Linux team. It also represents most of the directly measurable Linux-related graphics business, which is why it gets the attention. If you see bugs being fixed which are not a priority to the consumer user community there's a pretty good chance they either *were* an issue for workstation or were a cross-OS issue which had been flagged as occuring on Linux as well as a "non-Linux OS".
We are also taking steps to have our QA groups try to reproduce problems reported here on our internal systems, making it possible for developers to do something about them, so you should start to see more alignment between community input and release note content over time.
Last edited by bridgman; 08-20-2008 at 11:22 PM.
08-21-2008, 01:03 AM
Bridgeman, this isn't a question, more so as perhaps a summary of the common ground for us consumer clients. Right now you have 3 'teams', as I understand, working on rolling releases for fglrx and while I can't speak for your enterprise or other business clients, it seems that most of the consumer clients feel left out in this setup.
What I would like to suggest, is perhaps a different way of going at this. Could it perhaps be worked that one team instead works on new features - such as the more complete crossfire support being worked on - while the other 2 teams be regrouped where 2/3 of them work on workstation level bugs and the other 1/3 on bugs that affect the consumer market?
I seems as though for the majority of us linux users, looking for better support on our home computers and laptops, there aren't all that many new features we desire, but we would love for the known bugs to be fixed. For example, when I read that crossfire support and adaptive anti-aliasing has been added I thought 'that's kinda neat. Doesn't do anything for me, but neat.' then saw that video tearing and the wine corruption still exists, I was suddenly rather meh about this release.
I know you guys are working hard, and that some of us tend to get really frustrated over some minor things, but it seems that we are presently more interested in bug fixes than fancy new features or minor performance enhancements.
08-21-2008, 01:26 AM
08-21-2008, 02:20 AM
08-21-2008, 02:31 AM
You can always "ignore" the releases and go by your own update schedule.
Originally Posted by djdoo
08-21-2008, 05:15 AM
Some example of bug reporting
I think that's actually what's missing: a way to report and follow reported bugs for the fglrx driver; maybe not as complete as Bugzilla, but the following should be more useful than a 'mere' forum.
Originally Posted by bridgman
Please note that I haven't tried Catalyst 8.8 yet (the bug may have been solved).
The 'checkerboard of doom' bug, for example, could be filed as:
OS: GNU/Linux (any)
Platform: x86, x86-64
Affected hardware: HD2xxx, HD3xxx, HD4xxx
Affected driver revisions: Catalyst 8.6, 8.7
Summary: some OpenGL applications trigger a display bug in fglrx that makes display unreadable.
Several 3D-intensive applications, usually ones that make use of a full-screen mode, may trigger a rendering bug which divides the screen in approx. 16px squares and scrambles them.
Affected applications are:
- Wine 0.9.58 to 1.1.2 (both D3D and WGL wrappers)
- Nexuiz (triggers bug at boot, but driver 8.7 restores itself)
- mplayer (with -vo gl2 used to make use of multitexture OpenGL renderer, switching back and forth may trigger the bug)
The bug is fatal with Catalyst 8.6 (system lockup), but 8.7 can restore itself after either a little while or when closing the trigger application.
Interestingly, when the bug is triggered, making a screen capture with e.g. GNOME's screen capture utility displays no corruption in the captured snapshot.
Steps to reproduce:
1 - connect affected card (here, HD 4850) to 1680x1050 screen through DVI
2 - start affected application
3 - stare at the screen dumbly :P
Reproducible: on affected systems, always.
Description of bug reporter's platform:
- Nvidia 6150 chipset-based motherboard (Asus A8N-VM CSM)
- Athlon X2 3800+, socket 939 version
- 2 Gb of DDR400 in dual channel
- Mandriva 2008.1 Free x86-64 with all updates and backports applied
- distribution-provided 8.6 driver, manually installed 8.7 driver
Other platforms displayed the bug as well.
08-21-2008, 11:39 AM
Let's get this out of the way first. We do not have multiple teams rotating through releases. It may appear that way because we have a mainline and release branches where we freeze code for QA test and final bug fixing, but we do not rotate teams or releases. It's all one group.
Originally Posted by wfeltmate
One of the problems here is that a lot of the things you think of as "bugs" (eg video tearing) are actually "lack of features". Syncing video playback to vblank is one of the areas where the current X/DRI stack has always had problems (and is in the process of being re-written again), while Windows and MacOS have had a framework to support this for years.
Originally Posted by wfeltmate
Video tearing will be fixed by adding new features to the drivers, not by "fixing a bug" -- if it was just a question of fixing bugs we probably would have done that already.
I see some posts about "why are you adding features like overclocking ?" but overdrive, powerplay and thermal management are all different aspects of the same code. As we finish integrating power management into the Linux drivers things like Overdrive more-or-less come along for free. I guess we could leave them completely hidden but I don't think that would save much time or eliminate any bugs because we need to set everything up properly anyways.
I'm actually surprised that nobody is talking about the improved multi-head support we added in 8.8. That is by far the most disruptive change but it is also one of the most requested features we hear about.
We do understand your needs (and your frustration) and that was one of the reasons we kicked off the open source driver initiative last year. I expect that over time most consumer users will gravitate to the open source driver, since it is targeted precisely at those requirements -- simple driver, core functionality, and able to be tweaked to match your specific distribution so things like suspend/resume work reliably for relatively more users.
Originally Posted by wfeltmate
Right now there are two remaining things which need to be addressed in order to make the open source driver viable for general consumer use -- addition of a decent memory manager in the kernel (which allows the implementation of GL 2.0 functionality), and support for the 6xx/7xx 3d engine (which allows more acceleration to be added to the HD2xxx-HD4xxx drivers than the shadowfb acceleration we have today). The first task is being worked on by the community, with Dave Airlie taking the lead, and the second task is being worked on by AMD and Novell developers.
The proprietary driver will be the vehicle for delivering maximum performance and functionality, but I see it as an "upgrade path" for consumer users if they are looking for something more than the open source driver can provide.
Last edited by bridgman; 08-21-2008 at 11:57 AM.