New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 649200 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocking:
issue 649101



Sign in to add a comment

conformance/extensions/webgl-depth-texture.html fails with --enable-unsafe-es3-apis

Project Member Reported by zmo@chromium.org, Sep 22 2016

Issue description

It happens on at least NVidia and AMD GPUs, so I assume this is a generic issue in ANGLE.
 

Comment 1 by zmo@chromium.org, Sep 22 2016

Cc: kbr@chromium.org
Components: Internals>GPU>ANGLE
Owner: jmad...@chromium.org
Status: Assigned (was: Available)
Owner: zmo@chromium.org
The depth texture is coming up black because ANGLE is rejecting it as incomplete:

    // OpenGLES 3.0.2 spec section 3.8.13 states that a texture is not mipmap complete if:
    // The internalformat specified for the texture arrays is a sized internal depth or
    // depth and stencil format (see table 3.13), the value of TEXTURE_COMPARE_-
    // MODE is NONE, and either the magnification filter is not NEAREST or the mini-
    // fication filter is neither NEAREST nor NEAREST_MIPMAP_NEAREST.

This is also in the latest 3.0.4 spec on page 161, also section 3.8.13.

Here command buffer is sending ANGLE GL_LINEAR for the min and mag filters, and ANGLE is doing the correct thing in drawing black.

Sending to you Mo for the command buffer update (or any last-minute spec updates you need to enact).
Note this is a change from the ES2 extension to ES3. The test is probably correct. I don't really think linear filtering makes sense for a lot of depth/stencil formats, so I'd suggest working around this in command buffer by replacing LINEAR with NEAREST and mipmapped linear with mipmapped nearest.

Comment 5 by zmo@chromium.org, Sep 22 2016

Owner: jmad...@chromium.org
What we pass down to ANGLE is internalformat == GL_DEPTH_COMPONENT, since ANGLE still advertises ANGLE_depth_texture extension in ES3, and still allows this unsized internalformat, ANGLE should not fall back to black texture in this case.

We also checked on other ES3 drivers in Andoid.  They also exposes OES_depth_texture and this test is passing.

In the meantime, per discussion with kbr, we will not expose WEBGL_depth_texture on ES3 without ANGLE_depth_texture or OES_depth_texture extension. (I will take care of this, but this is not blocking 649101, the ANGLE side fix is)
I think we should probably not expose this extension in ANGLE ES3 because of this problem.

ES3 is clear in that the 'effective' internal format is the sized format that represents the format,type unsized format pair, and the language on pg 161 of the 3.0.4 spec uses the 'effective' format. I could be reading this wrong, but it seems to cover unsized depth formats as well.

Comment 7 by zmo@chromium.org, Sep 22 2016

I agree with jmadill's proposal in commen 4 and 6.

To summarize:
1) we should not expose ANGLE_depth_texture in ANGLE ES3
2) in command buffer, if we are reporting CHROMIUM_depth_texture on top of ES3, we should replacing LINEAR with NEAREST and mimapped LINEAR with mimapped NEAREST.
3) we will not change the WEBGL_depth_texture spec in case we break existing contents. however, we should change the conformance test to use NEAREST, not to further promote LINEAR.

Comment 8 by zmo@chromium.org, Sep 23 2016

Further looking into the problem, it seems the easiest solution is to allow unsized formats to be filterable with non-nearest filters in ES3 with ANGLE_depth_texture.

1) sized formats are not exposed in WEBGL_depth_texture extension because TexStorage isn't exposed, so we only need to relax the constraints for unsized formats

2) many ES3 drivers do the same with OES_depth_texture
To expand on what Mo said in #8, I read into the Khronos issues on this, and saw a definitely lack of interest in supporting these old ES2 extensions. There's some incompatibilities with other extensions (and with the ES compatibility desktop extensions) and edge cases. The spec maintainers basically shrugged and driver writers may be free to behave inconsistently.

Comment 10 by kbr@chromium.org, Sep 23 2016

Understood and agreed. I think we should make the minimum change possible in order to move to ES3 everywhere, but most importantly, not break existing WebGL content. I think that continuing to render unsized depth textures from WEBGL_depth_texture that are using LINEAR filtering, rather than making them incomplete, is important. If they're demoted to NEAREST filtering internally that seems fine.

Project Member

Comment 11 by bugdroid1@chromium.org, Sep 23 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/32dd62b8976b5a93e6ddc631b3cfb55fbb208032

commit 32dd62b8976b5a93e6ddc631b3cfb55fbb208032
Author: Jamie Madill <jmadill@chromium.org>
Date: Fri Sep 23 18:09:06 2016

Allow LINEAR filtering on OES_depth_texture formats.

The ES3 spec and this extension lead to some awkward interactions. The
extension doesn't mention allowed filtering modes, so be default it
allows both linear and nearest. ES3 however, very clearly restricts
any depth texture (any texture with effective internal format which
has depth or stencil bits) to only use nearest filtering. This then
breaks compatibility with the legazy unsized formats.

Choose to be slightly non-conformant here, and allow linear filtering
for the older unsized formats. Although this could lead to problems
down the line, it is consistent with existing ES drivers in practice.

Other future options might be to override the behaviour of the filter
to use nearest when using WebGL validation compatibility.

BUG= chromium:649200 

Change-Id: I4ee7608dd04d1fd238385aefee32c8c9c1e80ca0
Reviewed-on: https://chromium-review.googlesource.com/388759
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>

[modify] https://crrev.com/32dd62b8976b5a93e6ddc631b3cfb55fbb208032/src/libANGLE/Texture.cpp

Project Member

Comment 12 by bugdroid1@chromium.org, Sep 23 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/angle/angle/+/32dd62b8976b5a93e6ddc631b3cfb55fbb208032

commit 32dd62b8976b5a93e6ddc631b3cfb55fbb208032
Author: Jamie Madill <jmadill@chromium.org>
Date: Fri Sep 23 18:09:06 2016

Allow LINEAR filtering on OES_depth_texture formats.

The ES3 spec and this extension lead to some awkward interactions. The
extension doesn't mention allowed filtering modes, so be default it
allows both linear and nearest. ES3 however, very clearly restricts
any depth texture (any texture with effective internal format which
has depth or stencil bits) to only use nearest filtering. This then
breaks compatibility with the legazy unsized formats.

Choose to be slightly non-conformant here, and allow linear filtering
for the older unsized formats. Although this could lead to problems
down the line, it is consistent with existing ES drivers in practice.

Other future options might be to override the behaviour of the filter
to use nearest when using WebGL validation compatibility.

BUG= chromium:649200 

Change-Id: I4ee7608dd04d1fd238385aefee32c8c9c1e80ca0
Reviewed-on: https://chromium-review.googlesource.com/388759
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>

[modify] https://crrev.com/32dd62b8976b5a93e6ddc631b3cfb55fbb208032/src/libANGLE/Texture.cpp

Project Member

Comment 13 by bugdroid1@chromium.org, Sep 23 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f507a4425364347073fa5e07fd90d8b2ba6084c5

commit f507a4425364347073fa5e07fd90d8b2ba6084c5
Author: zmo <zmo@chromium.org>
Date: Fri Sep 23 23:15:13 2016

Roll ANGLE 28a97ee..e8a7849

https://chromium.googlesource.com/angle/angle.git/+log/28a97ee..e8a7849

BUG= chromium:649101 , chromium:649200 
TBR=kbr@chromium.org,jmadill@chromium.org
TEST=bots

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2360203005
Cr-Commit-Position: refs/heads/master@{#420773}

[modify] https://crrev.com/f507a4425364347073fa5e07fd90d8b2ba6084c5/DEPS

Project Member

Comment 14 by bugdroid1@chromium.org, Sep 24 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a4589e6cdc603a7d597339c964f78e6f2b4f4c66

commit a4589e6cdc603a7d597339c964f78e6f2b4f4c66
Author: zmo <zmo@chromium.org>
Date: Sat Sep 24 01:04:01 2016

Command buffer should not report depth_texture on pure ES3 without depth_texture extension.

BUG= 649200 
TEST=gpu bots
R=kbr@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2363773007
Cr-Commit-Position: refs/heads/master@{#420803}

[modify] https://crrev.com/a4589e6cdc603a7d597339c964f78e6f2b4f4c66/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/a4589e6cdc603a7d597339c964f78e6f2b4f4c66/gpu/command_buffer/service/feature_info_unittest.cc
[modify] https://crrev.com/a4589e6cdc603a7d597339c964f78e6f2b4f4c66/gpu/command_buffer/service/texture_manager.cc
[modify] https://crrev.com/a4589e6cdc603a7d597339c964f78e6f2b4f4c66/third_party/WebKit/Source/modules/webgl/WebGLDepthTexture.cpp

Status: Fixed (was: Assigned)
Components: -Internals>GPU>WebGL Blink>WebGL

Sign in to add a comment