Open Radar

 
Summary:

In low VRAM situations, OpenGL textures previously populated on the GPU are being corrupted. This corruption has been witnessed on Mac OS X on various GPUs for some time. However, some progress appears to have been made in 10.8; we can no longer provoke the texture corruption on AMD GPUs (tested with an AMD Radeon HD 6490M). The problem is still reproducible on NVIDIA and Intel GPUs, however.


Steps to Reproduce:

1. In current Chrome on a machine with either an NVIDIA GeForce GT 330M or Intel HD Graphics 3000 GPU, visit maps.google.com and enable MapsGL.
2. In five separate tabs, navigate to:
2a. Seattle, WA
2b. San Francisco, CA
2c. New York, NY
2d. Chicago, IL
2e. Austin, TX

For the Intel HD Graphics 3000, add the following four:
2f. St. Louis, MO
2g. Milwaukee, WI
2h. Portland, OR
2i. Las Vegas, NV

3. For each tab, zoom in far enough that the 3D buildings begin to show up, and drag around the map a little.
4. Once the last tab is loaded, cycle through the tabs in order. When a tab is newly exposed, it will often show garbage. Dragging around the map will cause it to clear up.


Expected Results:

Expect maps to render correctly.


Actual Results:

Garbage is rendered to the screen in place of the map.


Regression:

Not a new bug in 10.8, but behavior seems to have improved in 10.8 on AMD GPUs. We would like to see improvements made on Intel and NVIDIA GPUs as well.


Notes:

When switching tabs, the web page is simply re-composited; the map's most recent render, which was performed into an OpenGL texture, is drawn to the screen. The map itself is not re-rendered. The fact that just the map is corrupted, and not other page elements, indicates that the corrupted textures are those whose contents came from rendering to that texture, and not those whose contents were uploaded from system memory. For this reason we suspect a bug in the paging of textures back from the GPU into system memory.

Moving the map around slightly clears up the corruption because the map is re-rendered to that texture, and then the web page is composited again.

In the WebGL conformance suite it has been observed that attempting to allocate many large textures never returns a GL_OUT_OF_MEMORY error, but always seems to succeed; eventually, however, some previously uploaded texture will be spontaneously corrupted. It is impossible for client applications to handle this silent corruption. Returning a GL_OUT_OF_MEMORY error would be better behavior.