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

Issue 890002 link

Starred by 2 users

Issue metadata

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

Blocking:
issue angleproject:2894



Sign in to add a comment

WebGL2 with Pixel2 device: GL.readPixels always returns GL.INVALID_OPERATION

Reported by xavier.b...@polytechnique.org, Sep 27

Issue description

Steps to reproduce the problem:
1. Take a Google Pixel2 device
2. Check that it runs Android9/Chrome69
3. Open the unit test showing the bug here: https://jeeliz.com/tests/readPixels/

The source code of the unit test is here: https://gist.github.com/xavierjs/ebe0a7bca5ebb78959069ff9726421d6 

What is the expected behavior?
GL.readPixels(0, 0, 1,1, GL.RGBA, GL.UNSIGNED_BYTE, _readBufferPixel); 
const glErr=GL.getError();

should return GL.NO_ERROR

What went wrong?
const _readBufferPixel=new Uint8Array(4);
GL.readPixels(0, 0, 1,1, GL.RGBA, GL.UNSIGNED_BYTE, _readBufferPixel); always return GL.INVALID_OPERATION
const glErr=GL.getError();

I tested the unit test with other configurations and there is no problem at all (other devices, other browsers, ...).

I took another look to the WebGL1 and 2 specs, I don't understand why.

Did this work before? N/A 

Chrome version: 69  Channel: stable
OS Version: 9
Flash Version:
 
Labels: Needs-triage-Mobile
Cc: chelamcherla@chromium.org
Components: UI>Browser>Mobile Blink>WebGL
Labels: Target-71 M-71 Triaged-Mobile FoundIn-71
Status: Untriaged (was: Unconfirmed)
Tested the issue in Android and able to reproduce the issue. 

Steps Followed:
1. Navigated to https://jeeliz.com/tests/readPixels/ and observed Srggggg :( Bro, sthing has gone bad :( popup

Chrome versions tested:
60.0.3072.0 , 69.0.3497.100, 71.0.3563.0

OS:
Android 9.0.0

Android Devices:
Pixel 2 , Pixel 2 XL

Issue is seen from older M-60 builds, hence considering this issue as Non-Regression and marking as Untriaged.

NOTE: Issue is working fine in Samsung s7 -- Observing Everything is fine bro message

Please navigate to below link for log's  --
go/chrome-androidlogs/890002

Thanks!
Hi,

Thank you very much for your reactivity and professionalism :).
Good luck to solve the bug.

Have a great day!
Cc: -chelamcherla@chromium.org sindhu.chelamcherla@chromium.org kainino@chromium.org
Owner: kbr@chromium.org
Status: Assigned (was: Untriaged)
Owner: jdarpinian@chromium.org
Just triaging this, yes, this is happening and it's unclear why.

James, could I please ask you to investigate this? Some API call (not clear whether it's ReadPixels) is generating INVALID_OPERATION on the Pixel 2 where it isn't on another device I tested on (Samsung Galaxy S7). Thanks.

It looks like this is an error in Qualcomm's implementation of EXT_multisampled_render_to_texture. ReadPixels is supposed to do an implicit resolve of the multisampled buffer, but instead the driver is reporting GL_INVALID_OPERATION (which would be correct behavior if EXT_multisampled_render_to_texture was not supported).
Argh. Thanks for getting to the bottom of this James. Can we implement a workaround for this bug? I have a feeling that just blacklisting EXT_multisampled_render_to_texture will cost too much performance on these mobile GPUs.

Could we also add a dEQP test for this? I'm pretty sure it has tests for extensions like EXT_multisampled_render_to_texture, and there's probably a missing test. The last time I did this, I checked out https://github.com/KhronosGroup/VK-GL-CTS and https://android.googlesource.com/platform/external/cherry side-by-side and used a Makefile derived from one of Kai's to build things. Will attach that in the next comment.

Makefile originally from Kai which builds the appropriate targets in the vk-gl-cts to run the dEQP under Cherry.

Makefile
1.4 KB View Download
I'm updating the WebGL conformance tests to catch this bug here: https://github.com/KhronosGroup/WebGL/pull/2729
Blocking: angleproject:2894
While implementing the dEQP test for the bug I found that it is triggered by the presence of a depth/stencil attachment on the FBO. I then tried to work around the issue by creating a new FBO with the same color attachment and no depth/stencil.  However, this seemed to trigger another driver bug that caused the returned pixels from ReadPixels to be incorrect.

Instead, I'm going with a workaround that duplicates the backbuffer texture using copyTexImage2D before calling ReadPixels. That seems to work although it does use more temporary memory. It might be possible to work around the second driver bug with some more investigation but I think it is low priority. Since EXT_multisampled_render_to_texture is not directly exposed to WebGL it is not possible to trigger that bug from web content.
Project Member

Comment 13 by bugdroid1@chromium.org, Oct 19

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

commit 98d07198bf8ca5d73651c727d229a4468b700d43
Author: James Darpinian <jdarpinian@chromium.org>
Date: Fri Oct 19 23:42:02 2018

Workaround for Qualcomm driver bug in glReadPixels.

When using EXT_multisampled_render_to_texture, glReadPixels fails in
recent Qualcomm Adreno drivers. glCopyTexImage2D still works, so the
workaround is to create a temporary texture, glCopyTexImage2D, and then
glReadPixels from the temporary texture.

WebGL conformance test updates for this bug are here:
https://github.com/KhronosGroup/WebGL/pull/2729

This workaround will be revisited in the passthrough command decoder
and ANGLE when the switch is made to use those for WebGL on Android.

dEQP test is here:
https://android-review.googlesource.com/c/platform/external/deqp/+/796566

Bug:  890002 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I6254242258411997fcfbb3f0145801b398073778
Reviewed-on: https://chromium-review.googlesource.com/c/1279354
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601356}
[modify] https://crrev.com/98d07198bf8ca5d73651c727d229a4468b700d43/gpu/command_buffer/service/framebuffer_manager.cc
[modify] https://crrev.com/98d07198bf8ca5d73651c727d229a4468b700d43/gpu/command_buffer/service/framebuffer_manager.h
[modify] https://crrev.com/98d07198bf8ca5d73651c727d229a4468b700d43/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/98d07198bf8ca5d73651c727d229a4468b700d43/gpu/config/gpu_driver_bug_list.json
[modify] https://crrev.com/98d07198bf8ca5d73651c727d229a4468b700d43/gpu/config/gpu_workaround_list.txt

Project Member

Comment 14 by bugdroid1@chromium.org, Oct 22

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

commit 5bc9e7dd586a2d1d53762c8e091df5a5c820e2b2
Author: James Darpinian <jdarpinian@chromium.org>
Date: Mon Oct 22 19:45:29 2018

Fix null dereference caught by ClusterFuzz.

In http://crrev.com/c/1279354, I didn't consider that the bound read
framebuffer can be NULL when reading from the default framebuffer.

Bug:  897402 ,  890002 
Change-Id: Id033ee7108d6bdceb9646e3e36595bfe667625a1
Reviewed-on: https://chromium-review.googlesource.com/c/1294401
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601691}
[modify] https://crrev.com/5bc9e7dd586a2d1d53762c8e091df5a5c820e2b2/gpu/command_buffer/service/gles2_cmd_decoder.cc

Project Member

Comment 15 by bugdroid1@chromium.org, Oct 24

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

commit 319faa6f9fc6bb050759c111202dbb61ba99086d
Author: Kenneth Russell <kbr@chromium.org>
Date: Wed Oct 24 17:21:44 2018

Roll WebGL 6d2f3f4..0d55c88

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/6d2f3f4..0d55c88

Includes suppressions for the following failures:

  conformance/rendering/rendering-sampling-feedback-loop.html
  conformance2/textures/misc/tex-mipmap-levels.html
  conformance2/textures/image_bitmap_from_video/
    tex-2d-rgb565-rgb-unsigned_short_5_6_5.html
  deqp/functional/gles3/lifetime.html
  deqp/functional/gles3/shaderoperator/common_functions_*.html

Bug: 660844,  739604 , 766918, 849576, 886970,  890002 , 890539,  898350 ,  898351 ,  angleproject:2832 
Cq-Include-Trybots: luci.chromium.try:win_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_angle_rel_ng;luci.chromium.try:win_angle_rel_ng
Change-Id: I85be441fa86090e5ed056a9366452248985693e3
Reviewed-on: https://chromium-review.googlesource.com/c/1297570
Reviewed-by: James Darpinian <jdarpinian@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602377}
[modify] https://crrev.com/319faa6f9fc6bb050759c111202dbb61ba99086d/DEPS
[modify] https://crrev.com/319faa6f9fc6bb050759c111202dbb61ba99086d/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
[modify] https://crrev.com/319faa6f9fc6bb050759c111202dbb61ba99086d/content/test/gpu/gpu_tests/webgl_conformance_expectations.py
[modify] https://crrev.com/319faa6f9fc6bb050759c111202dbb61ba99086d/content/test/gpu/gpu_tests/webgl_conformance_revision.txt

Status: Fixed (was: Assigned)
Thanks for the bug report! The fix is in Canary and Dev channel. It will be released with Chrome 72, currently scheduled for the end of January.

Sign in to add a comment