Open-Source Radeon HD 6000 Series Still Borked

[allquixotic]

Good catch. The "fact" is that we will be able to work on open source driver design in parallel with proprietary driver design for the first time. The "hoped for outcome" is solid open source driver support closer to launch time, and possibly the first launch-time support for a new generation of discrete GPUs.

Yeah, but define "support"? If you mean just the initial 15,000+ line commit by Alex to bring initial "rough cut" 2d and basic 3d making it into git a week before launch day, that's not what anyone's hoping for. Judging from recent history (HD5000 support bringup), these initial commits usually need 3 - 6 months of work to produce a driver that's remotely useful for consumers.

What we'd really like to see is, essentially, reaching feature and stability parity with what the R600-class GPUs are currently enjoying with r600g, months before the card's official retail launch. Months, because it takes that long for distros to grab the changes into a release.

I know you said "solid open source driver support", so are you referring to the situation in my first paragraph, or more along the lines of the latter situation? I'm not trolling or expecting more than is achievable here; I just want to know your honest opinion as to what you believe can be accomplished if the open source team is involved from the very start.

Also, since so much important work goes into the driver from non-AMD employees, hopefully you'll be able to provide reference boards to people like Dave Airlie and Marek Olsak, months before official retail availability. Either that, or hire on more developers to do work on the new ASICs before general availability in lieu of the spectacular work by non-AMD employees. Without that extra community help, you're gonna need more in-house manpower, or else find a way to enlist that community help in the pre-release stages.

To meet the lofty goal of "solid" open source support on launch day, you'd really have to up the ante on this whole process. That initial 15,000 line commit would have to land a good 6 - 8 months ahead of general availability, followed shortly by getting reference boards out to anyone from the community you've managed to enlist for help. Then you need to coordinate between the community, your own developers, and the distros, to try and squeeze the driver into the release schedule of the distros currently in development. This can be a real pain if the timing works out poorly; if your driver support is on the rise just as the big distros are putting on the brakes on the release cycle, they may push back at you for making too big of a change, too late in the game for them. And of course nobody expects you to time your releases so they're in sync with Ubuntu releases.

You also have to contend with the Linux kernel release cycle, since you pretty much have to get your DRM changes into a merge window 6 months before you want to see it in a distro. And that's if you get lucky and the kernel release gets picked up by the distro during the development cycle; sometimes a kernel is released later in the cycle and not picked up by the distro.

All in all, conservatively, the current development process of distros and the Linux kernel would require you to get that initial code into mainline starting about 8 months before the card's general availability. That's a really lofty goal to reach, I think, and much more demanding of proper foresight than any other platform. On Windows (or on Linux with fglrx for that matter), you can literally write 50% of your code a month before GA and still be able to get a Catalyst release pushed out to the website before GA. Huge difference, 1 month vs (conservatively) 8.

Now that I've analyzed the release cycle this way, I feel awfully cynical about this. Even if AMD technically "does their job" and gets a solid, well-working driver into Linux git and fd.o git by release day, it'll still be between 6 months and a year before mainstream users can just install a stable distro and benefit from that. This situation is extremely frustrating. I wish we could do something about it. It's highly unacceptable.

The problem is just the release cycles and the way they conflict, I guess. Getting things into mesa on time for a release; getting things into the kernel on time; getting both mesa and the kernel rolled into a distro release over the heads of cautious package maintainers. Nobody wants to be responsible for breaking anything, so everyone just sits on their hands until code has been out in the open for a year or so. That's too long, when you're upgrading your graphics card every 2 - 3 years.

What I'd really like to see is some distros proactively working with AMD and community Mesa developers to pull in as much recent, known-to-work code as possible into a release, going as far as backporting DRM to the distro's chosen kernel version, and doing a distro build of Mesa based on a git commit rather than a stable release (mesa stables are way too few and far between IMHO). Instead of being reactive and just idly pulling in the latest stable release each cycle (yawn, boring), distros should be proactive and try to get the latest and greatest code that they can, provided that it's been tested and developers are on-hand to fix any issues that crop up. If you had this kind of close cooperation with Ubuntu and Fedora and OpenSUSE, you could give yourselves a bit less of a head cramp with the 8 month lead time, cutting it down to maybe 3 or 4 months. That would give you more time to write the driver, and allow for late-breaking hardware changes that require driver changes. And then you might even be able to get supported drivers out to the distros by release day...!!!

It's a dream I've been chasing for a long time, but realistically I'll probably be compiling from git until such time as I retire from the PC gaming scene and have no more use for a current graphics card.

[smitty3268]

In the bug report, Alex just posted a couple of kernel patches that one tester says has fixed things for him. Hopefully this will be working in the final 3.0 kernel.

[jcgeny]

There is people that also care about freedom and open source code and in my point of view on the long term open source code is always better because it gives you freedom (you not dependant from any company to provide you something that they might stop at any moment for what ever reasons).

freedom ... i agree that publishing source code is a great idea and the best way to have bugs removed and fastest execution of it .

there are few hardware makers that sell billions of chips per years like realtek ,intel , nv-ati . they also create drivers for linux , i think it is clever to use them because they are the best and "free of charge" for a linux kernel maker and in fact paid by users-consumers .
by the way , it is with linux , like with wiwi : every body installs hardware drivers ; that are not working well with all distros ...

[bridgman]

I know you said "solid open source driver support", so are you referring to the situation in my first paragraph, or more along the lines of the latter situation? I'm not trolling or expecting more than is achievable here; I just want to know your honest opinion as to what you believe can be accomplished if the open source team is involved from the very start.

By "solid support" I am referring to something more along the lines of the latter situation, but I don't expect it to be available "months before release". We already provide upstream support for CPU features before release, but GPU timelines tend to be a lot tighter than they are for CPUs, and the amount of "must have" software-visible change is 1-2 orders of magnitude larger.

Also, since so much important work goes into the driver from non-AMD employees, hopefully you'll be able to provide reference boards to people like Dave Airlie and Marek Olsak, months before official retail availability. Either that, or hire on more developers to do work on the new ASICs before general availability in lieu of the spectacular work by non-AMD employees. Without that extra community help, you're gonna need more in-house manpower, or else find a way to enlist that community help in the pre-release stages.

I think everyone agrees that more developer-months of work are required before launch. This requires more developers, more months, or both. What we are talking about here is basically adding more months to the equation by starting earlier. GPU hardware tends to arrive relatively later in the development cycles than CPU hardware, so throwing more developers at the problem late in the cycle is not as practical as you would think.

Now that I've analyzed the release cycle this way, I feel awfully cynical about this. Even if AMD technically "does their job" and gets a solid, well-working driver into Linux git and fd.o git by release day, it'll still be between 6 months and a year before mainstream users can just install a stable distro and benefit from that. This situation is extremely frustrating. I wish we could do something about it. It's highly unacceptable.

Things are already being done about it AFAIK. You've probably noticed that "server distros" are maintaining their slow, careful release cycles while "desktop distros" are moving towards more frequent releases, rolling releases, and generally getting closer to the upstream code every year. Some distros such as Fedora have been running *ahead* of upstream where necessary. There's a reason for this - the traditional distro development cycles are tough to reconcile with the constant arrival of new hardware and user expectations of day-1 support.

What I'd really like to see is some distros proactively working with AMD and community Mesa developers to pull in as much recent, known-to-work code as possible into a release, going as far as backporting DRM to the distro's chosen kernel version

This has actually been going on for a while, and agd5f has been structuring the driver code where possible to make this a relatively low risk activity.

It's a dream I've been chasing for a long time, but realistically I'll probably be compiling from git until such time as I retire from the PC gaming scene and have no more use for a current graphics card.

Once you start compiling from git it's hard to stop - there's always going to be some new feature or fix that you might as well pick up because it's there. What I can say is that a lot of people understand the problems you are talking about here, and that things are going to continue to improve. I doubt the solution will take the form of "initial support upstream 8 months before launch" but there are a lot of other options as well.

[darkbasic]

Once you start compiling from git it's hard to stop - there's always going to be some new feature or fix that you might as well pick up because it's there.

I do agree, that's why I switched from debian to gentoo

[chrisr]

What we'd really like to see is, essentially, reaching feature and stability parity with what the R600-class GPUs are currently enjoying with r600g, months before the card's official retail launch.

My RV790 is working very well these days too. (Compiz, World of Warcraft, XVideo, KMS). Perhaps not "feature complete", but certainly more in the "fewer FPS" than "missing textures and random artifacts" state, which is considerably more bearable.

[darkbasic]

My RV790 is working very well these days too

That's because R600~=R700, they share the vast majority of code and they were developed in the same time
Actually my HD3870 is already much faster with open drivers than an X1950 XTX which is the most powerful R500 card, I am probably going to buy an HD4890.

[Drago]

This thing of constant chasing release cycles got already boring. Wouldn't be good idea to separate drm from the kernel completely, and distribute it like separate non-mainline kernel module. Just like the binary blobs do. That way, driver releases could be made much more frequent, and Linus will not curse us every other kernel release over *bad* code.

[crazycheese]

another example that some others software like drivers made by ati or nvidia , or even the "Tuxera NTFS" and nftfs M$ filesystem should be used .
linux would earn a lot to use whats best

opensource > closed source
commercial != closed source
no one needs ntfs and other redmond junk
troll be gone

[crazycheese]

That's because R600~=R700, they share the vast majority of code and they were developed in the same time
Actually my HD3870 is already much faster with open drivers than an X1950 XTX which is the most powerful R500 card, I am probably going to buy an HD4890.

4870/90 are extreme hot and big cards, which get pwned by evergreen easily. Go evergreen. I would, if open drivers would be more useable(to me).