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.
Catalyst 3.8 Problems ; ATi responds
Posted on Monday, October 20 2003 @ 22:48 CEST by Thomas De MaesschalckI found the full response from ATi regarding the overheat/monitor failure issues with the Catalyst 3.8 drivers over at [H]ardOCP :
