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:
@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:
Did the test case added in #3221 address this gap?
I think so!