Catalyst 3.8 Problems ; ATi responds

I found the full response from ATi regarding the overheat/monitor failure issues with the Catalyst 3.8 drivers over at [H]ardOCP :

RESPONSE TO ALLEGED MONITOR FAILURE ISSUE

We have spent a great deal of time trying to reproduce this problem and analyzing our driver code. There is nothing in our driver code that has changed since CAT 3.7 to CAT 3.8 that could possibly cause this behaviour. We believe that our drivers are not causing these alleged problems. We do not currently believe these stories are valid. We have already confirmed that of the nearly 100 OEM customer programs have asked for and received this driver, we have received no reports on any such problem from the OEMs. We have also run comprehensive QA tests on the driver before releasing it and have had no cases of failed monitors.

Since we announced CATALYST 3.8 on October 8th, we have recorded hundreds of thousands of downloads, and thus far there have been absolutely no reports whatsoever to ATI's Customer Support department to report monitors failing.


RESPONSE TO ALLEGED HARDWARE OVERHEATING ISSUE

We have spent a great deal of time analyzing the temperatures due to the CATALYST 3.8 drivers. We do not under any circumstance see anything near a 10 degree Celsius increase in temperature (but we don't overclock our test cards either). We do see a slight increase in temperature in certain cases (3Dmark2003 Nature Scene for example). However any temperature increase is well within our safety range. Investigation continues and we are trying to determine why this change in temperature exits. At this point we are reproducing individual driver packages with code being checked in and measuring the temperature. However nothing shows the alleged increase in temperature. One independent website even tried to reproduce this issue, and found no measurable difference in temperature between CATALYST 3.7 and 3.8.


TECHNICAL REBUTTAL OF MONITOR FAILURE ALLEGATIONS

There have been many posts in the forums discussing this issue, it seems it is a common theory, picked up from one place and keep being circulated. One such theory suggests the following:

"Instead of reading the refresh rates from the PRIMARY display INF files, it is reading the SECONDARY display INF refresh rates."

In XP and 2K, we don't have access to monitor INF information in our driver component that manages display capability. We have never used this monitor information for any purpose. We rely on EDID data or user override information to determine monitor capability. Even though the OS may use the monitor information to expose high refresh rate based on monitor INF content, the driver always restricts the actual refresh rate going to the monitor based on EDID or the user override. In essence, the user may be able to select from OS controlled monitor page (in advanced property pages) a high refresh rate but internally driver will restrict the refresh rate going to the monitor based on EDID information or user override information. If user set the override information incorrectly then incompatible signals would be sent to the monitor.

In 9x, we can access monitor INF information but due to issues with how OS maps the INF to a monitor, we had disabled reading the monitor INF via registry. Unless someone deliberately changes the registry setting for this in 9x, they would not run into any monitor INF related issues.