My horrible experience with ATI

[mtippett]

@mtippett

If patching fglrx drivers is so easy, why don't provide OFFICIAL patches? That is common for Nvidia drivers too, i have got a full collection of em...

Simply because we don't plan for support of a new kernel until we are approaching the release of a distro-support update. Our OFFICIAL support comes out as part of the driver release. Depending on the requisite changes you may see support for a kernel earlier, but it definitely won't be announced or implied as a higher level of support.

The 2.6.29 and 2.6.30 kernels have had quite a bit of impacting changes that have mean non-trivial changes. For AC/DC power switching there is still work that needs to be done.

Nvidia has a different approach. I would expect that the NV approach is unofficial and unsupported patches that are posted as a convenience.

Regards,

Matthew

[Kano]

I understand that 2.6.29+ needs more changes, but there has been a long rc phase for 2.6.29 (beginning in january) and also 2.6.29 has been out since 20-Feb-2009 which was 4 (!) month before 9-6. Wouldnt you call that extremely slow to adopt those changes? Nv has 4 official drivers which do not require a single patch for 2.6.31 and one "stable" driver that needs one little patch.

[mtippett]

I understand that 2.6.29+ needs more changes, but there has been a long rc phase for 2.6.29 (beginning in january) and also 2.6.29 has been out since 20-Feb-2009 which was 4 (!) month before 9-6. Wouldnt you call that extremely slow to adopt those changes? Nv has 4 official drivers which do not require a single patch for 2.6.31 and one "stable" driver that needs one little patch.

By our stated policy, it hasn't been slow. 1) No supported distribution has updated to 2.6.29 or later so we don't need to start until closer to the distro updates and 2) the changes needed a non-trivial.

Slow is a relative term. Slower than you like, yes. Faster than distro-updates, no.

We know the state of the NV drivers, it is unlikely that the "2.6.31" support is complete, AC/DC switching for example. We have plans in place to ensure that the work is complete - or at least clearly documented.

Matt

[Kano]

Well Ubuntu karmic has 2.6.31 rc3 already, if you support U then you would need an update really soon. I don't think it was reasonable to give U a special driver for last bigger change just in time for release. It is certainly better when it is tested longer.

[TrentZ]

Wouldn't be better to ditch KCL and use (open-source) DRM instead? That way fglrx could support KMS also.

[Nille]

Wouldn't be better to ditch KCL and use (open-source) DRM instead? That way fglrx could support KMS also.

In the DRM is the memory managment and many other stuff from ATI and i dont think they want/cant open it.

[bridgman]

The problem is that you would have to give up a lot of the performance advantages we get from the proprietary code, particularly the memory manager.

The 3D stack is built around our own common code; moving the 3D driver onto the open drm would mean :

(a) a lot of work to do the porting,

(b) inability to use a common stack across OSes, ie more time spent maintaining Linux-specific 3D code and less time available to work on other Linux-specific stuff,

(c) lower performance and stability under high load.

Besides, look at all the grief Via is getting for trying to run a closed 3D driver over an open DRM

[PuckPoltergeist]

Simply because we don't plan for support of a new kernel until we are approaching the release of a distro-support update. Our OFFICIAL support comes out as part of the driver release. Depending on the requisite changes you may see support for a kernel earlier, but it definitely won't be announced or implied as a higher level of support.

The 2.6.29 and 2.6.30 kernels have had quite a bit of impacting changes that have mean non-trivial changes. For AC/DC power switching there is still work that needs to be done.

Impacting changes to what? Ok, for 2.6.29 the answer isn't too hard. But there are still some steps in betwenn.
With the kernel releases the changes grow more and more. And with every release it should be harder to adapt the fglrx-driver. It should be a lot of easier to patch the driver early.

And releasing those drivers doesn't mean official support automatically. AMD can support the drivers which fit to distributions and the rest is unsupported or beta.

[PuckPoltergeist]

Simply because we don't plan for support of a new kernel until we are approaching the release of a distro-support update.

Apropos support, AMD shouldn't write into System Requierements "Linux kernel 2.6 or above" if it isn't supported.

And where should bugs be reported so that they're noticed by the AMD/ATI-Developers? The xserver still can't be quit outside from X.

[doubledr]

Apropos support, AMD shouldn't write into System Requierements "Linux kernel 2.6 or above" if it isn't supported.

Agree. IMO, this is a fraud, seriously.

Please clearly indicate the range of the support kernels.