ati catalyst 10.6 released

[rohcQaH]

They [AMD/ATI] only care about supported distros [..] not Linux in general.

If your view is limited to fglrx, then you can certainly make such claims.

(Then again, I've never had a single problem on gentoo. Good packaging is everything. If your distro stinks, don't blame ati.)

Often you get a new driver with absolutely no diff to the one before.

can you name two driver releases where several major components got the same md5sum?

[Kano]

You don't get the same md5sum when you just recompile the source and tag it differently. What changes did you see from 10-2 to 10-3? I did not see any! Then a preview release (8.712.3.1) with new OpenGL 4 appeared which was faster with Unigine 2.0 - out of the release shedule! Ok, 10-4 officially introduced Xserver 1.7+ support, 10-5 fixed a rendering bug with xvba. 10-6 added more errors than it solved - i updated my script now to add ALWAYS a BusID entry, but it worked long without. Also that new 2d "accelleration" shows more black boxes than it accellerates, i do not need that driver, the also added .33 support i patch for ages and .34 support was still needed.

[rohcQaH]

Well, then do a binary diff to show they're mostly identical.

Each release contains the latest version of the driver core, but those changes are neither documented nor do they have to be easily visible by you or me. Doesn't mean they aren't there. Obviously something was changed between 10.2 and 10.3..

[Kano]

The preview driver had opengl code similar to 10-5, as it came out about the same day as 10-3 i did not use that long (maybe a few h), but it lost of course the Unigine benchmark i tested back then. I did not test other games, those are not important for me. A game that runs > 60 hz all the time is boring to test.

[tmpdir]

The differences are just too small for monthly releases. Often you get a new driver with absolutely no diff to the one before. Maybe 1 pci id more or so. Nv times new releases when new products are out, new kernels, new xservers. That's definitely better.

Its for everyone theirselfs to decide if the drivers is upgrade worthy or not. If you have no need for it, than let it be.

I've not seen the driver release with only one pci id patch, that indeed would be hilarious. But keep in mind even an empty release note could still mean there are a lot of changes. It all depends on their release policy.

But... I still think the driver lacks quality and noticable progress (besides the wooo haa stories and the excellent marketing strategies). This driver is one of the few versions worth 'my' time to install. The current quality is not much better than the time I bought my first (and last) ATI gpu. On that part I totally agree with you.

[RealNC]

If your view is limited to fglrx, then you can certainly make such claims.

(Then again, I've never had a single problem on gentoo. Good packaging is everything. If your distro stinks, don't blame ati.)

I'm talking about fglrx, yes. And I'm on Gentoo. And it still doesn't work with newest X.Org. And how will "good packaging" result in fglrx supporting newest X and kernel? Oh yes, the magical packager will solve this.

[Minigun]

RealNC:

I too am on Gentoo. I'm using kernel 2.6.34-gentoo-r1 and xorg-server 1.8.1.901. Had no problems (except too lazy power-saving features) with catalyst 10.6. I'm now using catalyst 10.5 with the no backfill patch.

What do you mean the driver "doesn't work" with newest xorg?

[bridgman]

Well, we've been criticizing AMD/ATI for ages now about this, but they've repeatedly told us that they simply don't give a **** about recent X and kernels. They only care about supported distros (and then only with their default settings and packages; tweakers should go screw themselves) not Linux in general.

So you can talk and talk all day long. They simply, and officially, don't care about this.

It would be correct to say that we have simply, and officially, told you that we have been treating support for new X and kernel versions as a lower priority than making improvements in core areas of the driver stack. We have also told you that we are gradually improving support for new X/kernel versions (ie shortening the delay) and that we expect those improvements to continue.

Regarding monthly driver releases, remember that we share a lot of code across multiple OSes, so even a driver which has no apparent changes probably has a thousand or more invisible changes in the code as a result of work done in common code for future GPU support or for new, not yet released features.

These changes often end up helping some users even if others don't see a benefit - which is why you see conflicting reports with each new release, generally a mix of "boring, nothing new here" and "hey, this is fixes my xxx problem, this is the best release yet". It is highly unlikely that any of the monthly releases would ever include unchanged components.

Sometimes these invisible changes cause unexpected problems on specific systems or scenarios which don't get caught during QA - again, finding those early is better than letting them pile up and producing an uber-release which works nicely for 90% of our users and is unuseable by 10%.

[Kano]

Can you logically explain why 12 driver releases are needed? You can release 6 or 20 drivers too, just depending if there is a purpose for it. Just developing 3 drivers in parallel which each containing only minimal changes is a very stupid thing.

[bridgman]

The main reason is that a lot of code is shared so we can leverage the testing cycles done for the Windows Catalyst drivers, which come out 12 times a year. If the Windows drivers were released 6 or 20 times a year then we would probably follow that cycle. If we didn't have a lot of cross-OS code in the drivers I would probably go for quarterly releases rather than monthly. That's where we are trying to go with the open source stack.

The "3 drivers in parallel every three months" thing is a rumour someone started a couple of years ago. We have never done anything like that.

We do overlap final QA on one major release with early development on another, but that kind of pipelining is pretty common practice.