Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

[bridgman]

Normally we rely on user and developer feedback to help determine hardware dependencies for problems, but we aren't seeing much feedback yet. I suspect that when the first user published that they had problems other users simply didn't try the code, which meant that we didn't get as many of the "it works on my system" and "it doesn't work on my system" reports which help to track down problems. We did get the feedback about running fglrx first, which is a big help.

The community developers would normally have been testing the code by now but most of them are working on r600g instead.

[allquixotic]

...Insightful comments...

Sorry, sounds like I was a bit off my rocker this in the day

I was under the (perhaps incorrect) impression of the following: once a driver is rendering correctly and seems to nominally support the features it's supposed to, making it work fast is basically an effort that is left to non-ATI developers. If they can reverse engineer fglrx to figure out how to get the last performance out of it, great. If they can come up with the code themselves, great. But because fglrx itself has techniques that ATI isn't comfortable with exposing to potential competitors, they leave these last optimizations out, allowing the driver's ultimate performance level (long term) to be decided by external contributors.

Now if that's off base, then I'm sorry. If the ATI legal team would accept a commit from an ATI employee who is putting forth a "crown jewels" style commit that may contain ATI-patented software algorithms (which obviously would have some unique benefit for the features or performance of the driver), that's heartening. What you've claimed is that, if there were only time and manpower to get it done, the open source drivers could be made to be as fast as fglrx, and the legal review team would be fine with that? If I were hearing this from any other person, I would be reluctant to buy it; but coming from you, I accept it.

How about a stronger, more abstract claim? Consider whether getting the most out of the hardware (in terms of performance and features) is compatible with the filtering imposed by the legal review process; i.e., the review process would not filter out potentially beneficial code just because it has some sort of proprietary value to ATI.

If the two are indeed compatible, that is great. If not, we may reach a point where ATI's open source devs can not contribute further, even if they know what needs to be done. I would be more understanding if there were, in principle, a way to accomplish the same task without falling under the scope of your "IP", but what if -- hypothetically -- there were no other way? The hardware only functions a certain way, and maybe this is far-fetched, but perhaps there is only one best way to accomplish a certain task, or reach a certain level of performance. If that way is under some sort of trade secret or patent protection, I would wager that the legal team would hesitate, if not outright block the contribution, provided that the contribution is coming directly from an ATI employee. No? Then maybe I've misjudged the character of ATI as a for-profit corporate entity with an aggressive "intellectual property" protection policy.

I regret that I've interpreted your policies as being bad for software freedom if in fact they are not, which is seeming the more likely alternative. I don't want the big wigs to conclude that those FOSS zealots are more trouble than they're worth, so I'll leave you be.

Bah ... Now I feel like I'm just looking for a way to salvage my original argument by making some spin-off claim that may have more validity, but maybe I'm still wrong, so I'll quit while I'm ahead. I am so accustomed to corporate competitiveness screwing over open source projects that I've almost come to expect it. Sometimes people are just trying to get things done. I respect that.

[pingufunkybeat]

I don't think that the performance of fglrx is better because of secret code, or at least that "secret code" is not the major factor.

The way I understand it, fglrx performs better because it has had about a thousand man-years of optimization invested in it, whereas the OSS driver has had maybe one man-year. If you invest a similar amount of time, you should approach similar performance, but it's tricky and annoying business.

Also, the optimizations tend to make the code ugly and unreadable and difficult to maintain, so some optimisations will not be accepted in an open-source project anyway.

[rohcQaH]

Normally we rely on user and developer feedback to help determine hardware dependencies for problems, but we aren't seeing much feedback yet.

if you need something from the user community, you could have done the simple thing: ask.

I've specifically asked if I should file proper bug reports about the things I'm seeing. I'm sure you've all read the question, yet I didn't even get a simple "yes, add all the information you can" or "we know about it already, but we have yet to determine why it happens or which systems are affected.". I sure would have spent more time trying to boil it down to a testcase (instead of playing guild wars) if I had known it would be useful.
If you really needed testers, you could have asked Michael to add a small news item "AMD wants you to test the evergreen code!"; he gets the hits and you get the results.

The official information said that you moved on to fusion, and it appeared you were just leaving the evergreen bugs behind to meet the "fusion OSS drivers on release" goal. As often, it took some ramblings of a misinformed user to get some reassuring statements from you - should we all learn from that?


Now I know that posting on phoronix isn't part of your job description and that all of you are doing awesome work, given the difficulty of the subject and the understaffing. Still, I think a bit more communication could have made a difference here.
Or are there any other (non-dev) communication channels I'm not aware of?

[bridgman]

I was travelling for the last couple of weeks and wasn't able to keep up with all the forum traffic. When I'm back in town, get home from work, but can't get to sleep I sometimes have a chance to catch up and that's what you are seeing now.

We weren't stalled waiting for user feedback or anything, my comments were more related to "why don't you give Richard a system that fails ?" rather than "why aren't you making progress ?".

I don't remember any "official information" saying that we had moved on to Fusion (or hypothetical future discrete GPUs) and were not working on Evergreen. There are various rumours floating around but AFAIK none of them are true and I don't have time right now to hunt them all down and respond to them. Anything related to work on unreleased hardware is particularly difficult to respond to and I'm not even trying to go there right now.

Unless you hear otherwise, assume that everything is "business as usual", ie the developers are splitting time between a number of different activities, and that we will tend to shift to working on the next generation of hardware once we have basic working functionality on a previous generation so that we can gradually catch up with the rate of new product introduction.

[bridgman]

It probably goes without saying that until we have the current GPU hangs & corruption resolved on Evergreen that work will remain a high priority...

... but I'll say it anyways just for clarity

[rohcQaH]

The "rumours" were straight from phoronix, sounded like he quoted you:

Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs
Additionally, John will be re-tasking AMD's open-source developers within a week or two. With the foundation of the Evergreen 2D/3D/video support now laid, AMD will leave the rest up to the open-source community to complete while John will take AMD's limited internal developers and begin working on their next-generation support.

But you have restored my faith, I'm sorry for wavering, and I'll repent by finishing that testcase I was working on

https://bugs.freedesktop.org/show_bug.cgi?id=29986

[bridgman]

The "rumours" were straight from phoronix, sounded like he quoted you:

But you have restored my faith, I'm sorry for wavering, and I'll repent by finishing that testcase I was working on

https://bugs.freedesktop.org/show_bug.cgi?id=29986

Michael did accurately represent what I said during our discussion.

That said, rather than "in a week or two" I guess a more complete statement (from me) would have been "until we get any obvious hardware programming issues resolved and reach the point where the remaining work does not require access to internal hardware information, which I expect to be in a week or two, but which could be longer or shorter depending on the issues we find after initial release".

I was definitely expecting a week or two of post-release gotcha-fixing, but there was a bigger difference between what users saw and what we saw internally than we had seen on previous initial code drops.

EDIT - just noticed that the initial release was only 13 days ago, so maybe "a week or two" will still turn out to be an OK guess

[monraaf]

remember a opensource driver with bugs is more than no opensource driver.

That's a good one. I'll throw it right back at you later this month when you're having problems again with the latest catalyst release.

It doesn't matter if the driver isn't working for you, just remember a non working driver is better than no driver at all!

[bridgman]

You do have to give him points for "everGr800n" though