1281181 - WebGL depth texture sampling does not work

Status: NEW

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[marcot]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

created scene that:
1 - renders 2 spheres: one near the camera (on the left), one that is far (on the right)
2 - renders a full screen quad to change the color of the two spheres based on their distance from the camera, sampling from the depth texture



Actual results:

both spheres are rendered with the same color (white - like the background)



Expected results:

left sphere should be dark, right sphere should be grey. check in Chrome to see expected results.

Comment 1

[marcot]

repro: https://oc.unity3d.com/index.php/s/8JdkjrsflVvWIVn

Safari works fine too.

Comment 2

[marcot]

- This was reproduced on OSX 10.11.2 (15C50) with NVIDIA GeForce GT 750M 
- It does not reproduce on Windows 10 with NVIDIA GeForce GTX 960

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

Jeff, can you have a look? Thanks!

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Any chance for a regression range?  This is tagged as having regressed in Firefox 50, meaning since June 6th, so it shouldn't be a problem to find the changeset that caused it, using mozregression.

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

marcot, in case you don't know it, mozregression is an interactive regression range finder, you can find it here:
http://mozilla.github.io/mozregression/

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

I can reproduce this, I'll try to get the regression range.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: Errors on some of the older Firefox nightlies

What do we make of this error?  (This particular one from 2016-01-24 nightly.)

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Doesn't seem to be E10S related, but could be just on the Nightlies.

Comment 9

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Firefox: 50.0a1, Build ID  20160629030209
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0

I have tested this issue using a Mac Book Pro (with Intel Iris Graphics 6100) on the latest Firefox (47.0) release and latest Nightly (50.0a1) build, but I could not reproduce it. For testing this I have used the provided test case from comment 1 and the left sphere was dark and the right sphere was grey.

I have also tested on the Nightly build from 2016-01-24, and I was able to reproduce the errors described in comment 7. I have performed a find fix regression and this are the results: 

First good revision: 78bd3a5e7968df4535c711f4665a707be91e8f11
Last bad revision: f6e4f2f869a326e461989bd4c821b7228ee45cb5
Pushlog: https://goo.gl/pO0QIW

Looks like the following bug has the changes which introduced the fix:
https://bugzilla.mozilla.org/show_bug.cgi?id=1243907

Comment 10

[marcot]

(In reply to Cosmin Muntean [:CosminMCG] from comment #9)
> Firefox: 50.0a1, Build ID  20160629030209
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0)
> Gecko/20100101 Firefox/50.0
> 
> I have tested this issue using a Mac Book Pro (with Intel Iris Graphics
> 6100) on the latest Firefox (47.0) release and latest Nightly (50.0a1)
> build, but I could not reproduce it. For testing this I have used the
> provided test case from comment 1 and the left sphere was dark and the right
> sphere was grey.

could it be specific to an webgl extension that for you (with Intel Iris Graphics 6100) is not available ?

Comment 11

[marcot]

(In reply to Milan Sreckovic [:milan] from comment #4)
> Any chance for a regression range?  This is tagged as having regressed in
> Firefox 50, meaning since June 6th, so it shouldn't be a problem to find the
> changeset that caused it, using mozregression.

sorry for the delay. Here are the results:

 8:18.65 INFO: Narrowed inbound regression window from [0babaa3e, 66fb8529] (4 revisions) to [f143af51, 66fb8529] (2 revisions) (~1 steps left)
 8:18.65 INFO: Oh noes, no (more) inbound revisions :(
 8:18.65 INFO: Last good revision: f143af51f6e35932927b8ccac2509facbbe7b539
 8:18.65 INFO: First bad revision: 66fb852962c0d5f6f5fe0604204da4f5d17763c9
 8:18.65 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f143af51f6e35932927b8ccac2509facbbe7b539&tochange=66fb852962c0d5f6f5fe0604204da4f5d17763c9

Comment 12

[Jukka Jylänki]

Marco, the regression window you posted corresponds to the time when WebGL 2 was enabled in Nightly without requiring setting any prefs. In current latest Nightly, if I run with the default prefs that have WebGL 2 is enabled, I can reproduce the issue (fully white screen) on my Macbook Pro (Early 2013, OS X 10.11.1). In that run, the page gets a WebGL 2 context.

However if I run latest Nightly with the pref webgl.enable-prototype-webgl2 set to false, the page gets a WebGL 1 context, and the render looks as expected (two spheres, left one fully black, right one shaded gray).

Can you describe what the fallback code path is like for that sample in WebGL 1? Does it do something fully different that e.g. doesn't sample depth textures, and therefore renders the test case invalid if WebGL 1 context is obtained? Or if the relevant code paths stay the same in WebGL 1 vs WebGL 2, do we perhaps have a Firefox WebGL issue that only manifests if one initializes a WebGL 2 context(?)

Clearing the needinfo, the regression window is in the above comment, though I don't think this is a regression, but like mentioned above, I think the bug was just surfaced when WebGL 2 was enabled by default.

Comment 13

[Jukka Jylänki]

When running the test case on OS X, there is a message

   Error: WebGL: validateProgram: Implemented as a no-op on Mac to work around crashes.

that is printed to console. That doesn't look related in any way to the issue at hand in this bug. Marked down bug 1284425 to discuss this message.

Comment 14

[u279076]

I am clearing the regression keywords based on the assessment in comment 12.

Comment 15

[ithompson4]

[testday-20170217] Confirmed that this problem still persists ref https://threejs.org/examples/#webgl_depth_texture

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

Peter, can you have somebody look at this ?

Comment 17

[Daosheng Mu[:daoshengmu]]

I can reproduce it from Comment 1. The error log is "Error: WebGL warning: validateProgram: Implemented as a no-op on Mac to work around crashes.".

But I saw Safari has the same wrong result. Btw, My laptop is OSX 10.12, HD Graphics 4000, and on same Mac laptops with the dedicated GPU card are correct.

Comment 18

[Daosheng Mu[:daoshengmu]]

(In reply to Daosheng Mu[:daoshengmu] from comment #17)
> I can reproduce it from Comment 1. The error log is "Error: WebGL warning:
> validateProgram: Implemented as a no-op on Mac to work around crashes.".
> 
> But I saw Safari has the same wrong result. Btw, My laptop is OSX 10.12, HD
> Graphics 4000, and on same Mac laptops with the dedicated GPU card are
> correct.

Sorry. I wanna correct my comment. I saw Safari, FF Nightly, Chrome have the same correct result. (two spheres, left one fully black, right one shaded gray) My laptop is OSX 10.12, HD Graphics 4000.

On another Mac laptops with the dedicated GPU card is wrong by getting a whole image.

Comment 19

[Daosheng Mu[:daoshengmu]]

(In reply to ithompson4 from comment #15)
> [testday-20170217] Confirmed that this problem still persists ref
> https://threejs.org/examples/#webgl_depth_texture

The reason of this example can't be run is WEBGL_depth_texture is the extension only for WebGL 1 . For Chrome and Firefox, both support WebGL 2 already. So 'if ( !renderer.extensions.get('WEBGL_depth_texture') ) {' is redundant here.

If you make 'enable-webgl2' to be false, the demo will work fine.

Comment 20

[Daosheng Mu[:daoshengmu]]

We can check the status of 

gl::GLFeature::packed_depth_stencil && 
(gl::GLFeature::depth_texture || gl::GLContext::ANGLE_depth_texture)

on Mac laptops with the dedicated GPU card.

Comment 21

[Kelsey Gilbert [:jgilbert]]

gl::GLFeature::depth_texture should be true on all OSX machines, since it's core in GL2. We're always at least GL3.3 on OSX+WebGL2.
Sounds like we need to dig into what exactly isn't working.

Comment 22

[Daosheng Mu[:daoshengmu]]

This only can be reproduced on OSX with NV GPU. Intel and AMD GPUs are good.

The example from https://threejs.org/examples/#webgl_depth_texture actually works well on my test machine, but https://oc.unity3d.com/index.php/s/8JdkjrsflVvWIVn still does not work.

The difference between them is the three.js demo uses LOCAL_GL_DEPTH_COMPONENT format as its depth texture but the Unity demo uses LOCAL_GL_RED format with R16 internalformat.

Btw, Chrome 59 is good on both demos.


marcot, could you help me check whether you use GL_RED format as the depth texture?

Comment 23

[Daosheng Mu[:daoshengmu]]

On MacOSX with NV GPU, running https://oc.unity3d.com/index.php/s/8JdkjrsflVvWIVn, it will show "Error: WebGL warning: checkFramebufferStatus: Framebuffer not complete. (status: 0x8cdd) Bad status according to the driver: 0x8cdd" while it calls gl->fCheckFramebufferStatus(LOCAL_GL_FRAMEBUFFER); and its mColorAttachments[0].mTexturePtr->mImageInfoArr[0].mFormat is RGB5_A1.

According to OpenGL ES 3.0.5 (November 3, 2016)

• Texture and renderbuffer color formats (see section 4.4.2.2).
– RGBA32I, RGBA32UI, RGBA16I, RGBA16UI, RGBA8, RGBA8I, RGBA8UI, SRGB8_ALPHA8, RGB10_A2, RGB10_A2UI, RGBA4, and RGB5_A1.
– RGB8 and RGB565.
– RG32I, RG32UI, RG16I, RG16UI, RG8, RG8I, and RG8UI.
– R32I, R32UI, R16I, R16UI, R8, R8I, and R8UI.

It mentions RGB5_A1 should be available for renderbuffer.

I search some discussions from WebGL 2 spec [1] and Chromium [2][3][4], they mention this a NV driver bug on Mac. In Chromium, they seem to plan to convert RGB5_A1 to RGBA8 format to workaround this, but I didn't find the implementation yet. Jeff, do you think we should try to work around it?


[1] https://github.com/KhronosGroup/WebGL/pull/1755
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=612542#c26
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=616562#c4
[4] https://cs.chromium.org/chromium/src/third_party/angle/src/tests/gl_tests/WebGLFramebufferTest.cpp?q=rgb5_a1+cpp&dr=C&l=489

Comment 24

[Kelsey Gilbert [:jgilbert]]

Maybe? This format isn't guaranteed, technically speaking. I'm not sure it's worth polyfilling this.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.