AMD Radeon HD 5750/5770

[mirv]

The problem with fglrx is that it lacks about 2-3 month behind in several aspects:

a) kernel support
b) xorg support
c) hardware support

Nv tries to fix all 3 issues with new drivers in a way it does not take so long. There you get often kernel suport even for eary rc kernels, ati thinks they are forced to wait till the kernel is stable before they are allowed to download and test it. same applies for xorg. For hardware support issues the point is that most hardware basically works, but they tend to annoy people whereever they can using watermarks. Use a beta mark in logfile or as splash, thats really enough! To remove all watermarks look there:

http://www.phoronix.com/forums/showthread.php?t=19875

So if I can get this straight...watermarks on beta drivers not officially release by amd annoy the people that shouldn't (read: AMD doesn't intend for them to) have the drivers anyway?
I think we'll have to agree to disagree - I prefer AMD's monthly release cycle over nvidia's spontaneous approach, and I have no problems with a stable system being targeted first and foremost.

[Kano]

Well to avoid the signature check thats a trivial thing, one echo/sed and it is gone. To avoid the control / unsupported hardware check you can

a) analyse the content to be able to create it yourself (tried yesterday, but was unsuccessfull)
b) patch the binary (that worked)

monthly releases with absolutely no visual fix to 99% of the users are pointless.

[bridgman]

Kernel support and xorg support lag a bit because they are not high priorities. Hardware support generally does not lag, other than alignment issues between monthly driver releases and (occasionally) more frequent hardware launches.

We offer in-box Linux drivers to our board partners before launch; unfortunately once again only the Windows drivers were picked up and shipped with boards. We're making arrangements to post the launch driver separately. Hopefully board vendors will start including Linux drivers in the box at some point, which is how all the other OSes are handled today.

[Kano]

The ATI definition of "a bit" with 2-3 month is not my definition. Also you don't need to test all cards, as fglrx uses ATOM bios just like the oss driver - then lots of cards work - even without testing.

[mirv]

Releasing drivers without testing is generally a very bad idea - especially if you can test it on the hardware.

[Kano]

You can collect errors later anyway. All fglrx drivers are below beta quality of nvidia - absolutely no need to call em final. The partly funny thing is always the date when it was created compared to date of release, thats usally 2 weeks later. Nv would never wait that long.

[mirv]

You can collect errors later anyway. All fglrx drivers are below beta quality of nvidia - absolutely no need to call em final. The partly funny thing is always the date when it was created compared to date of release, thats usally 2 weeks later. Nv would never wait that long.

I'll steer clear of the nvidia comments (other than saying "huh?"), but again it would be unwise to simply "collect errors later". It's far better to not have the errors in the first place. Especially if errors lead to data loss or hardware failure - this can cause legal issues for the company, not to mention very bad PR.
And I'm being a little vocal tonight, hope people don't mind!

[Kano]

No errors would be nice, but that's pure theory for fglrx. Did you see a working (tearfree) XV with fglrx? I did never since R600 hardware was used! That means ATI is unable to fix obious problems, which even the OSS driver could do in the first stages of support. That's absolutely poor.

[mirv]

To be fair, AMD haven't been focusing on xv (as far as I know) but rather in other areas (general stability, features, etc). And quite possibly new hardware support.

[bridgman]

If you check the dates, almost a year elapsed between initial textured video support (Feb 08) and the addition of tear-free code (Dec 08). Implementing tear-free video in the open source drivers in fglrx is more complex because of the architectural differences -- it's not a "bug in the code".