AMD Radeon Boards with 64-bit Vista drivers fail in glDrawPixels and glTexSubImage2D on Windows 7

Discussion created by KoVogeler on Apr 22, 2010
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    

2D Driver File Path       /REGISTRY/MACHINE/SYSTEM/ControlSet001/Control/CLASS/{4D36E968-E325-11CE-BFC1-08002BE10318}/0000

Direct3D Version  

OpenGL Version  

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        

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