New issue
Advanced search Search tips

Issue 682290 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue angleproject:1664
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

WebGL render to Depth Texture error in RADEON cards

Reported by javi.age...@gmail.com, Jan 18 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. Create a FBO
2. Attach several color textures and one depth texture
3. bind it, render some shapes, unbind it
4. draw a quad that reads back from Depth texture and draw the value on the screen

What is the expected behavior?
You should see the depth in the .x component of the sampled texture

What went wrong?
The resulting behaviour is very strange:

The first time we read from the depth texture the output is as expected, but in future frames the depth buffer shows the same value as in previous frame and it never changes.

The more strange thing is that during the rendering process the depth test works fine, as if in the depth buffer (which is the texture) contains the right depth value from the current frame.

But when sampled it always returns the wrong value.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

It only happens in RADEON cards. Im using a R9 series.

You can see the use case attached also in this URL:
http://tamats.com/projects/litegl/examples/deferred.html

Inside you will find a very basic deferred renderer, in the lower left corner you will see that the depth buffer doesnt change even when dragging the mouse to change the viewpoint. Also note that the image in the lower-right side shows weird illumination because it samples the wrong value.
 
webgl_radeon_bug.zip
90.1 KB Download

Comment 1 by kbr@chromium.org, Jan 18 2017

Cc: geoffl...@chromium.org
Components: Internals>GPU>ANGLE
Owner: jmad...@chromium.org
Status: Assigned (was: Unconfirmed)
I think this is a duplicate of a bug that's already fixed on Canary. Jamie, can you confirm?

Status: Available (was: Assigned)
Will try to look into this, but will be traveling for a few weeks. Leaving assigned to myself but marking available if anyone has time.
Mergedinto: angleproject:1664
Status: Duplicate (was: Available)
Actually does look like a duplicate of  issue angleproject:1664 . Closing as such, will verify tomorrow.

Sign in to add a comment