Rendered Pixel Data are badly displayed (trash on the screen). Depends chaotically on the width of the rectangle
We have serious problems with the latest AMD drivers for Radeon Boards (particularly from the X1900-Series as well as the HD 4300 and 4500 Series) if the operating system is Windows 7 64-bit and the running application is also 64-bit.
Means: The code in matter used to work properly in the past and it still works properly unless the operating system is window 7 and the architecture is 64-bits
When passing RGB- GL_UNSIGNED_BYTE pixel or GL_FLOAT depth data to the frame buffer using glDrawPixels, the process randomly fails beyond a certain minimum width [somewhere between 256 and 512] of the data rectangle. So the effect is independent from the height.
If the width is beyond that limit, there seems to be no strict rule on which value may produce trash on the screen. On can only say, that odd width is more likely to cause harm than multiples or powers of 2. It seems to be no simple alignment problem.
The same problem occurs in identical situations with the function glTexSubImage2D which at least is supposed to accept arbitrary width and height values. If the one fails the other fails as well and vice vers. So there is no means of substituting glDrawPixels by the latter functions for color data.
I could realize this problem in an independent sample application just filling the view with some sort of color texture. A modification of the width causes repeatable nonsense in the displayed pixel data.
I specifiy here the system parameters but I think, it is not the system but the driver who fails:
OS Name Microsoft Windows 7 Ultimate
Version 6.1.7600 Build 7600
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Manufacturer Hewlett-Packard
System Model HP xw4400 Workstation
System Type x64-based PC
Processor Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz, 2667 Mhz, 2 Core(s), 2 Logical Processor(s)
BIOS Version/Date Hewlett-Packard 786D7 v02.03, 04.04.2006
SMBIOS Version 2.4
Boot Device \Device\HarddiskVolume1
Hardware Abstraction Layer Version = "6.1.7600.16385"
Installed Physical Memory (RAM) 2,00 GB
Total Physical Memory 2,00 GB
Available Physical Memory 820 MB
Total Virtual Memory 4,00 GB
Available Virtual Memory 2,49 GB
Page File Space 2,00 GB
ATI Driver
Driver Packaging Version 8.593.100-100210a-095951E-ATI
Catalyst™ Version 10.2
Provider ATI Technologies Inc.
2D Driver Version 8.01.01.882
2D Driver File Path /REGISTRY/MACHINE/SYSTEM/ControlSet001/Control/CLASS/{4D36E968-E325-11CE-BFC1-08002BE10318}/0000
Direct3D Version 8.14.10.0647
OpenGL Version 6.14.10.8545
Catalyst™ Control Center Version 2010.0210.2339.42455
ATI Hardware
Primary Adapter
Graphics Card Manufacturer Built by ATI
Graphics Chipset Radeon X1900 Series
Device ID 7249
Vendor 1002
Subsystem ID 0B12
Subsystem Vendor ID 1002
Graphics Bus Capability PCI Express
Maximum Bus Setting PCI Express x16
BIOS Version 009.012.005.002
BIOS Part Number 113-A52021-110
BIOS Date 2006/04/24
Memory Size 512 MB
Memory Type DDR3
Core Clock in MHz 500 MHz
Memory Clock in MHz 594 MHz
I will not attach code because I sent the sample application to the support hotline. I post this issue also here because other people may suffer from similar problems.
The direct effect of this bug is, that one of our most important 3D-packages wouldn't work any more under the mentioned architecture. So there is a significant damage. On the other hand this isn't the first problem with glDrawPixels(). So we would like to encourage AMD to run representative tests on glDrawPixels and glTexSubImage2D before releasing drivers. Even if the problem should be fixed in 6 month, the defectous drivers - on time spread over the globe - will be resident on many systems and certainly also on the computer of the tester who either blocks or allows our next product release.
Thank you for your help
