KhronosGroup/WebGL

Add test for reading and writing to the different levels of the same texture

Closed this issue · 8 comments

This is not a feedback loop. Applications may use this rendering path for legitimate reasons such as using a custom shader for mipmap generation.

See example ANGLE CL on which you could write such a test:

https://chromium-review.googlesource.com/c/angle/angle/+/2367314/6/src/tests/gl_tests/WebGLCompatibilityTest.cpp#5080

@kenrussell FYI

I thought we had at least one of these!

It is possible there is one already. I didn't find it.

I believe Chrome and Firefox each have different bugs here:
https://jsfiddle.net/2cd9bupa/3/

// With USE_ALMOST_FEEDBACK:true, Firefox incorrectly believes there is texture sampling feedback, generating INVALID_OP
// With it false, Firefox correctly draws greenish to the bottom-left pixel.
// With either option, Chrome incorrectly renders the bottom-left pixel as black, not green.
This test is for depth textures.

We should double-check that color-textures work properly, but I do think that's the test we had, just not for depth.

The previous testcase was wrong, because I mixed up TEXTURE_MAX_LOD and TEXTURE_MAX_LEVEL! 🙃

It's a little weirder:
https://jsfiddle.net/2cd9bupa/7/

  • With USE_SAMPLING_FEEDBACK:true, Firefox correctly identifies Sampling Feedback and generates INVALID_OP.
    • Chrome does not detect or prevent this Sampling Feedback.
  • With USE_SAMPLING_FEEDBACK:false:
    • With USE_ALMOST_FEEDBACK:true, Firefox incorrectly considers the framebuffer incomplete because MAX_LEVEL is 0 but FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL is 1.
    • This is correct for non-immutable textures, but for immutable textures, this is allowed.
    • NB: This means that WebGL 1 cannot support this method, since it requires TexStorage.
  • With all combinations of options, Chrome incorrectly renders the bottom-left pixel as black, not green, and generates no error.

I have fixed this in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1692617

I still need to file a Chromium bug but FYI @kenrussell

Note that the ANGLE bugs associated with this issue are:

http://crbug.com/angleproject/4500
http://crbug.com/angleproject/4690

and older associated Chromium bug:

http://crbug.com/1066201

Did the test case added in #3221 address this gap?

I think so!