Unpleasant install experience. HD5850 Ubuntu 10.4.

[Panix]

FunkyRider, That type of logic is what leads to bugs taking forever to get fixed. Honestly the main problems with the ati driver are the lack of bug reporters that create good bug reports. I know that the ati developers sometimes take more than a month to even confirm bugs. Although, once the bug can be confirmed, and reproduced, usually the fix will be created. Once the fix is created, the time for release can range anywhere from a month (next driver) to three months.

Wait a second. How does that make sense? You want logic?: you don't have to be an ATI owner to notice a lot of complaints about bugs and issues. The complaints resurface after a version update. I read 'X still isn't fixed... or X still occurs...' So, they might not be official bug reports but the 'problem' is being stated but there's no fix. Is that not accurate???? It seems to be from what I'm reading.

[mugginz]

People just don't listen, get the fsck rid of your 5850 and buy a GTX 460 you will never be happier. Using a HD5000 in Linux now is like poking a chair leg into your ares!

I was wondering what that uncomfortable feeling was while I sit at my computer.

[DarkFoss]

Of course pairing an ATI card with a Nvidia chipset it could never be a Nvidia/bios issue lol

[Dandel]

Wait a second. How does that make sense? You want logic?: you don't have to be an ATI owner to notice a lot of complaints about bugs and issues. The complaints resurface after a version update. I read 'X still isn't fixed... or X still occurs...' So, they might not be official bug reports but the 'problem' is being stated but there's no fix. Is that not accurate???? It seems to be from what I'm reading.

short post:

When taken out of context, and given the huge variety of hardware, it is important to specifically eliminate as many variables as possible down. Major variables include Distribution, Video card, motherboard, processor, Total system memory, kernel version (and whether or not it's 32-bit or 64-bit), Xorg revision (if it's not what is included with the distro by default), Monitor resolution (Matters, but not that much), Program version (and possibly revision), library versions. To put thinks bluntly... Programs have too many variables, and sometimes the best choice is to simplify things to where the developer can get an easier handle on how to fix the bugs.


long post:

As for my logic... I can't really say... most of what is going on is people can't identify which bugs are causing what. I already know of a few bug reports which ati is working on fixing. Just to name a few, the Unigine Heaven opengl crash with tessellation, the bugs with GLX_SGI_video_sync not properly handling vblanks, and with Wine running Unreal tournament 3 locks up with occlusion failure.

Now as for your reading of "isn't fixed" and "Still occurs" for those who don't really understand, nor want to go through the long threads, you need to make a decent bug report and follow up... For example, these statements completely pulled out of context, don't help with figuring out the source of the bug.

These statements really need a bit more information... For example, when confirming the bug with different hardware, or distribution, you need to post something along the lines of...

blank occurs with Catalyst (Insert version #, 10.7 for example) driver, on (insert distribution, like Ubuntu 10.04 amd64).
(Insert hardware mini spec.)

If your going to mention another application, also follow the above sample, and mention which software is relevant. For example, if it's wine, identify which version of wine, and the version of the program, and do as much tracing so that the faulty series of calls are identified...

next case... Confirming the report, and a newer driver revision... pretty much follow the above. This simply is to help with eliminating how many pages the developer needs to read.

blank occurs with Catalyst (Insert version #, 10.7 for example) driver, on (insert distribution, like Ubuntu 10.04 amd64).

also, as for a good mini spec... all you really need is the following.

• Processor model and maker.
• Motherboard brand and model
• Total Ram
• Video card make and model (also mention slot type if it's not PCI-E 16x)

an example mini spec: (using my current machine as a sample)

AMD Athlon IIx4 630
Gigabyte GA-MA790XT-UD4P
4GB ddr3 memory
xfx Radeon hd 5770

also, as a good rule of thumb, if your bug reporting include some version numbers if it helps.

oh and also, if the bug appears in screen-shots also, it's good to catch those.

oh and on a last note... if the feature is not released officially, and is not working, that does not count as a valid bug... Although, this is because i give credit for having the feature in progress, but don't even expect it to work, because the feature is not even completed yet. (See XVBA, and vaapi support.)

also, as a final note... if the bug report says that they are able to reproduce the bug, that means that the process has started to where the bug can start to be fixed.

[Panix]

Well, my accusation is that not enough money or resources (or both) are not being applied to the ATI drivers in Linux. That being said, I suspect that the kernel and Xorg versions are the major variables in particular. I don't think mobo and RAM are so much and I think you named quite a few that doesn't seem to add much confusion or trouble in the sphere of things. I think the problem is that ATI seems to take their time with the revisions and assessing the state of the driver. This is good to a point but obviously something more is needed. I don't know if that's money or what. Of course, they will object to those complaints but I think the proof is in the pudding when improvements are still exceptionally slow and the capability in Windows is so much more greater proportionately speaking. Even if one would say that Windows market is so much more, Nvidia has the same situation but the amount of bugs or problems seem to be way less. There must be some reason many Linux users yell, 'use Nvidia, nevermind the damn closed code and use your computer!'

You're saying that most ATI owners don't explain the bugs or issues sufficiently or in detail enough for the developers? All these ATI owners don't report the bugs at all or do it insufficiently? How many Linux users own ATI cards? I say it's hard to believe that so many don't know how to submit a bug report or aren't helping when they do. I think those are excuses. I suspect there is a lack of organization in responding and not enough resources given, period.

Maybe too many developers everywhere get frustrated or annoyed when Joe Public User Gamer submits a bug saying 'this and this didn't work.' ATI devs want the user to explain it in developer and maintainer terms or they will barely look at it? I know that Launchpad for Ubuntu is notoriously bad for anyone giving attention to bugs. I doubt that's specific to Ubuntu devs or whoever addresses bug reports. If they are claiming the bugs are not expressed in terms or info that is enough to reproduce the problem or assess it fully, maybe they need to have a FAQ or point-by-point instructions so even dummys know exactly what info to give and how to provide it?

[Dandel]

Well, my accusation is that not enough money or resources (or both) are not being applied to the ATI drivers in Linux. That being said, I suspect that the kernel and Xorg versions are the major variables in particular. I don't think mobo and RAM are so much and I think you named quite a few that doesn't seem to add much confusion or trouble in the sphere of things. I think the problem is that ATI seems to take their time with the revisions and assessing the state of the driver. This is good to a point but obviously something more is needed. I don't know if that's money or what. Of course, they will object to those complaints but I think the proof is in the pudding when improvements are still exceptionally slow and the capability in Windows is so much more greater proportionately speaking. Even if one would say that Windows market is so much more, Nvidia has the same situation but the amount of bugs or problems seem to be way less. There must be some reason many Linux users yell, 'use Nvidia, nevermind the damn closed code and use your computer!'

Yes, that's fairly accurate... however, sometimes the bugs are specifically driver related, but happen only with a particular motherboard.

You're saying that most ATI owners don't explain the bugs or issues sufficiently or in detail enough for the developers?

Yes, the number one problem for developers is actually getting enough details to pinpoint the bug and reproduce the bug.

All these ATI owners don't report the bugs at all or do it insufficiently?

Getting people to actually report the bugs is a problem. Sometimes a developer is not even informed about this. For example, an android tablet that was sold recently at kmart for $150 as a weekly special had all of the devices with the exact same mac address. The support team didn't even know of the problem until about a week ago.

How many Linux users own ATI cards?

If i remember right, there was a poll a while back.

I say it's hard to believe that so many don't know how to submit a bug report or aren't helping when they do. I think those are excuses. I suspect there is a lack of organization in responding and not enough resources given, period.

Yes, many users do not know how to report a bug properly. For example, a user could make a report with only following information:

XMBC does not play video correctly and the video is only a colored block.

This in itself is not a good bug report. A better report would be.

XMBC does not play video correctly and the video is only a colored block.
Ubuntu 10.04
xbmc 9.04 ( Camelot)
Radeon hd5770
Catalyst 10.7

Note: This is an actual bug with the driver... The driver initializes part of the glsl code to the 0 matrix most likely. This bug in the driver still remains, however, the fix for xbmc was to initialize all the texture matrices to the identity during initialization.

Maybe too many developers everywhere get frustrated or annoyed when Joe Public User Gamer submits a bug saying 'this and this didn't work.' ATI devs want the user to explain it in developer and maintainer terms or they will barely look at it?

That is a possibility. As for a good example of bugs which are known and reproduced look at these to see how you go about reporting a bug.

Occlusion failure that causes application freeze.
Unigine Heaven with tessellation hangs the machine on 10.7
Missing vsync control GLX extension (Got overloaded at the end, but still points to the vsync methods not working right)

I know that Launchpad for Ubuntu is notoriously bad for anyone giving attention to bugs. I doubt that's specific to Ubuntu devs or whoever addresses bug reports. If they are claiming the bugs are not expressed in terms or info that is enough to reproduce the problem or assess it fully, maybe they need to have a FAQ or point-by-point instructions so even dummys know exactly what info to give and how to provide it?

Yes, that is very very true... Most users of Ubuntu just want things to work, and don't really care about how to get a proper bug report done. As for the testing of the ati driver, That is usually done by corporate big wigs who care more about the 3d modeling programs more than 3d games.
Although, this is slowly improving... one of the previous bug report links is an bug where the ati driver fails with wine, and the issue is related to the usage of the occlusion code.

A step by step instructions might be the way to go actually. Although, the instructions would need to be broken down into specific distributions and tell people what things to intentionally include with a bug report. 90% of the time the ubuntu bug report program automatically collects most of the information required to know which software is causing the bug, and then leave only certain parts left after that.

[Panix]

Sorry, I don't buy it. Fix the bug reporting process then. Take the Launchpad idea (which isn't bad) by listing the info requested/required and make it easy for the bug reporter to add the info. Invite them to use pastebin or show output and explain the steps. Request kernel, Xorg, distro and package versions or whatever helps identify and troubleshoot the bug.

Because what you're saying and what these 'ATI apologists' are always saying is that it's the ATI card owner's fault. They buy a $300 ATI card and you want to blame them for the bugs and issues because they're not 'reported in enough detail to troubleshoot.' Basically, ATI wants you to use Windows!

[Panix]

Btw, I do agree that it obviously helps to have as much info as possible, the steps used to install, maybe hardware info, which ATI driver ver., X.org/XServer ver., distro/kernel ver., what packages are installed etc. etc. etc. But, some of the bugs and issues reported are already known or ATI has sufficient info but the improvements are not forthcoming or they're so gradual to cause frustration among ATI owners. Some people don't care as much as they're more content with open source drivers and the fact they don't have to deal as much with manual configuration.

I have dealt with Nvidia cards and the driver install mostly. It's a major pain but I struggled through it. I installed the driver on four different distros (although three were debian-based and one was Fedora). I'm not sure what bugs I were to encounter but I didn't notice tons of issues. If I had to do the same with an ATI card and then encountered major issues that prevented enjoyment of the card, that would be beyond frustrating. Since the FOSS drivers are limited in features, some people decide they must use the binary blob. Since, the binary driver is more complicated for the user to install, they probably think it's important to have the majority of features available and for them to work as expected. Bugs that keep showing up after driver revisions must be very frustrating indeed.

[Jecos]

I have succesfully pinpointed this issue of Catalyst not working on my nforce 590 chipset (MCP55) as a 64bit only problem.

I have tested at least 3 different distros. arch, pclinuxos, ubuntu.
They all lockup when running 64bit fglrx. but when 32bit fglrx is running just fine.. arg.. that's not really what anyone would desire to be stuck with less than 4 gigs on a linux OS..

[Dandel]

I have succesfully pinpointed this issue of Catalyst not working on my nforce 590 chipset (MCP55) as a 64bit only problem.

I have tested at least 3 different distros. arch, pclinuxos, ubuntu.
They all lockup when running 64bit fglrx. but when 32bit fglrx is running just fine.. arg.. that's not really what anyone would desire to be stuck with less than 4 gigs on a linux OS..

This is good test feedback. So, if i'm reading what you said properly... You ran Arch linux, pclinuxos and ubuntu with both the 32-bit and 64-bit kernels, and the crashing only happens on the 64-bit kernel.