Where is Catalyst 9-1??

[bridgman]

The Windows and Linux drivers share a lot of common code, and that code shares a lot of regression test coverage. If we split the releases then we're splitting the code and losing the ability to leverage test coverage across the OSes. The end result would be lower effective test coverage on Linux and more problems slipping through.

[RealNC]

who is saying that the linux driver is waiting for the windows driver?

No one needs to actually say it because it's a fact that is easily proven by looking at the release date of every Linux Catalyst till now: they always, *always* appeared on the same day as the Windows release. So this is a fact.

I think it is a good thing they are coupled. This way we get a new driver every month the same time the windows people get one. Unlike some other graphics vendor, where you can wait ages ...

That is wrong thinking. We should get a driver when it's ready, not when the Windows version is ready. Right now, we have the situation of either getting an unfinished driver because it HAD to be release due to the Windows one getting released, or having to wait for the driver even though it's ready because the Windows one isn't ready yet.

[energyman]

who is saying that the linux driver is waiting for the windows driver?
I think it is a good thing they are coupled. This way we get a new driver every month the same time the windows people get one. Unlike some other graphics vendor, where you can wait ages ...

[RealNC]

Any plans to decouple the Linux release date from the Windows one? It doesn't make much sense at all right now. At least from the Linux user's point of view. There's no benefit to us to wait for the Windows release.

[bridgman]

We were largely closed over the holidays, so December releases were pushed a bit earlier and January releases were pushed a bit later. We do the same thing around other holidays but the shift is less so you really have to look hard to notice.

[smlbstcbr]

Bridgman can put some light on this matter...

[Heiko]

There is one thing we know for sure:
The delay is not caused by a Linux driver issue.

I don't believe AMD would delay the Windows driver because the Linux driver isn't ready yet. The other way around is quite possible.

As a hobbyist OpenGL developer I'm hoping for full OpenGL 3 support. Though I also would be satisfied with a fully working, stable and lightning fast Linux driver without any new extensions .

[RealNC]

The show stopper is that they don't want to release the Linux 9.1 before the Windows 9.1, and the Windows 9.1 is probably waiting for Microsoft certification. So that means we (Linux) are also waiting for Microsoft certification even though we shouldn't give a rat's ass about it.

[PuckPoltergeist]

Perhaps they're working on 2.6.29 support? As in 2.6.29 (pretty) much of the ACPI-Code they are using in the catalyst driver is getting private to the kernel, this will be a little bit more work to fix this. So maybe this is the show-stopper.

[Aphax]

but seriously, i found that the stuttering in doom3 for me was solely due to alsa. setting sound device to /dev/null in DoomConfig.cfg or just running timedemo was smooth. that was all fixed with doom3 1.3.1.1304. to be honest, though idsoft has done a great job with doom3, they could have done a little bit more maintaining the code - especially adding openal and smp support like quake4 and may be a little more graphics optimizations (hard shadows suck!).

the quake3 issue was worse. idsoft's quake3 always had that issue with oss and sound mmap. very fortunately ioquake3 sealed it all with openal .

and not to offend anyone of you, but playing with compiz turned on is probably asking for too much. especially on midrange graphics cards, it hurts. (i am not sure about aero in windows.) at least try to use a program like fusion-icon to temporarily switch to non-composite while playing games.

also, in my very honest opinion, linux kernel has only improved. after the golden 2.6.16, 2.6.19-2.6.21 were nightmare for me, but things began improving from 2.6.22 onwards and 2.6.24-2.6.28 have been rock solid. i feel 2.6.28 is *the* best . may be some tinkering with kernel options is required, but i feel even the stock ubuntu desktop/server kernels are very very good.

there may always be that odd corner hardware that has some peculiarities to be resolved with some kernel option. but in general, its a good idea to buy mainstream hardware that is known to play well with linux .

I've never used Compiz, but yeah I can imagine that could mess with 3D performance

Anyway, I've already tried disabling sound with Doom 3, by starting with +set s_nosound 1, but that didn't appear to really work since the game would consistently segfault after loading a map doing that.. I've tried switching to the OSS backend which also didn't make the stuttering I had go away, and now with 1304 (I've done most of my testing with different kernels and settings with 1304) it is still present I haven't tried setting the sound device to /dev/null however, so I'll give that a quick shot just to make sure my issue isn't something with ALSA after all.

I can't say I haven't been happy with any of the newer kernels though, aside from this Doom 3 thing everything's working swell