kbr@ Could you please take a look in to this issue?

Thanks!

Able to reproduce a difference on:

Chrome version	Chrome/61.0.3159.0
Operating system	Mac OS X 10.12.5
GPU0	VENDOR = 0x8086, DEVICE= 0x1626 *ACTIVE*
Machine model name	MacBookAir
Machine model version	7.2
GL_VENDOR	Intel Inc.
GL_RENDERER	Intel(R) HD Graphics 6000
GL_VERSION	4.1 INTEL-10.25.13

Thanks for the report Shrek! We'll look into it when we can.

Shrek, thanks for the report. Definitely reproducible. It also reproduces with --use-passthrough-cmd-decoder , so it doesn't seem to be a bug in Chrome's accumulation of queries (though it could still be), and reproduces with --use-angle=gl , so it isn't a bug in the D3D11 backend.

This is pretty mysterious. We'll investigate.

Thank you. Glad that it helps!

This bug is very strange. Disabling all of the other queries in the scene and adding logging to Chrome, the OpenGL driver is definitely returning true for GL_QUERY_RESULT_AVAILABLE for node[511]'s query instance.

Checking Firefox's code at https://dxr.mozilla.org/mozilla-central/source/dom/canvas/WebGLQuery.cpp , it looks like Chrome and Firefox are doing similar emulation; in this case, on macOS, translating GL_ANY_SAMPLES_PASSED_CONSERVATIVE into GL_ANY_SAMPLES_PASSED_EXT, 0x8C2F, which is in the OpenGL 3.2+ Core Profile. I tried switching this to emulate it with GL_ANY_SAMPLES_PASSED_CONSERVATIVE with the same result.

Tried turning off all the driver bug workarounds in the shader translator, thinking this might be a difference between Chrome and Firefox; no change. (I would have been surprised if this were responsible, because the query is counting the number of times the depth test actually passes, which is handled by the fixed function pipeline.)

I haven't added logging to figure out if Chrome's doing a context switch between the WebGL and compositor contexts while issuing all of the draw calls for this scene. Wondering if that might fool the driver, though it shouldn't for the GL_ANY_SAMPLES_PASSED target, which should be accurate.

Note that the query *does* return false when node[512] goes off the right side of the screen. But when it comes back into view (even though it's behind all of the other spheres), it claims to become visible again.

Going to put this on the back burner for now. Shrek, if you can reduce this any further (perhaps making another test case with a large quad which occludes a bunch of other, smaller quads?), that could be very useful and could potentially be added to the WebGL conformance suite. Thanks.

Deleted: occlusion.html 27.3 KB

occlusion.html 27.3 KB View Download

Debugging this a little more, the rendering loop is very tight:

[78599:775:0718/132034.252427:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kColorMask
[78599:775:0718/132034.252438:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kDepthMask
[78599:775:0718/132034.252451:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kUseProgram
[78599:775:0718/132034.252478:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kBindVertexArrayOES
[78599:775:0718/132034.252496:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kUniformMatrix4fvImmediate
[78599:775:0718/132034.252515:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kDrawElements
[78599:775:0718/132034.252586:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kColorMask
[78599:775:0718/132034.252600:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kDepthMask
[78599:775:0718/132034.252610:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kUseProgram
[78599:775:0718/132034.252632:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kBindVertexArrayOES
[78599:775:0718/132034.252653:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kUniformMatrix4fvImmediate
[78599:775:0718/132034.252674:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: Noop
[78599:775:0718/132034.252682:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kBeginQueryEXT
[78599:775:0718/132034.252701:ERROR:query_manager.cc(858)] use_arb_occlusion_query2_for_occlusion_query_boolean_
[78599:775:0718/132034.252721:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kDrawArrays
[78599:775:0718/132034.252774:ERROR:gles2_cmd_decoder.cc(5261)] [.Offscreen-For-WebGL-0x7fabeb896600]cmd: kEndQueryEXT

Still don't know why this behaves differently between Chrome and Firefox.

vmiura@ had the key insight. The spheres have to be sorted front-to-back in order for the occlusion queries to work as expected. And in order for this to be done, they have to be sorted *every frame* according to their model-view-projection matrix. Currently the sample sorts them once, at the beginning of time. This is suspicious, and is at least highly specialized to the geometry being rendered in this example.

Fundamentally, Array.prototype.sort() is not a stable sort -- see https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/sort (thanks kainino@ for confirming this). I think what is happening is two of the spheres have the same value from the comparison function, and Chrome's sort is returning a different result than Firefox's. Certainly, in the attached modified version, nodes[511] has an index of 256 in Chrome, and 511 in Firefox.

I'm quite convinced this is a bug in the sample and am closing as WontFix. Please provide a new version of the test if you think otherwise.

Deleted: occlusion.html 27.4 KB

occlusion.html 27.4 KB View Download

Thanks Ken for your time and explanation. Very helpful!