"Rats! WebGL hit a snag!" on Sketchfab VR mode |
||||||||||||
Issue descriptionChrome Version: 57.0.2943.3 canary OS: Android (Tested on a Pixel XL) What steps will reproduce the problem? (1) Visit A sketchfab model, like https://sketchfab.com/models/8d06874aac5246c59edb4adbe3606e0e (2) Should load successfully (3) Click the "VR" button in the lower right corner What is the expected result? Hopefully it enters VR mode correctly. What happens instead? "Rats! WebGL hit a snag!" It seems from the logs that one of the shader associated with the new elements that are loaded when bringing up VR mode (The VR floor, targeting reticle, etc) isn't linking, providing a lot of "getUniformLocation: program not linked" errors. This is probably an issue on the part of the page, but it shouldn't be causing a WebGL context loss either.
,
Dec 7 2016
Just confirmed that if we turn off Origin Trials (which prevents Sketchfab from using the native WebVR implementation) the page starts to work correctly. (It uses a WebVR polyfill at that point.) This probably means that despite my earlier theory this likely is explicitly WebVR related.
,
Dec 7 2016
Issue 671895 has been merged into this issue.
,
Dec 7 2016
Should we mark this bug as ReleaseBlock-Beta or ReleaseBlock-Stable? The first version of Beta with WebVR enabled will be shipped this Thursday.
,
Dec 7 2016
I don't think we'd block Beta for this, but we should fix this ASAP. I'll add an RB-S flag but honestly if we don't get this fixed by end of January then we have bigger issues ... ;-)
,
Dec 7 2016
Brandon, assigning to you but feel free to loop in anyone else if you can't get to it while you're out.
,
Dec 7 2016
Got a crash stack in the logs after a few more runs: 12-07 11:00:09.880 31841 31841 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 12-07 11:00:09.881 31841 31841 F DEBUG : Build fingerprint: 'google/marlin/marlin:7.1/NME60B/3231051:userdebug/dev-keys' 12-07 11:00:09.881 31841 31841 F DEBUG : Revision: '0' 12-07 11:00:09.881 31841 31841 F DEBUG : ABI: 'arm' 12-07 11:00:09.881 31841 31841 F DEBUG : pid: 30581, tid: 30607, name: CrGpuMain >>> com.chrome.canary:privileged_process0 <<< 12-07 11:00:09.881 31841 31841 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1e 12-07 11:00:09.881 31841 31841 F DEBUG : r0 00000002 r1 00000000 r2 ce3de6dc r3 00000003 12-07 11:00:09.881 31841 31841 F DEBUG : r4 ce3de600 r5 e2c97b10 r6 00000001 r7 00000000 12-07 11:00:09.881 31841 31841 F DEBUG : r8 00000000 r9 00000000 sl ce3de600 fp 00000004 12-07 11:00:09.881 31841 31841 F DEBUG : ip 00001f55 sp edcaef78 lr e23a041b pc e23a01ae cpsr 400f0030 12-07 11:00:09.893 31841 31841 F DEBUG : 12-07 11:00:09.893 31841 31841 F DEBUG : backtrace: 12-07 11:00:09.894 31841 31841 F DEBUG : #00 pc 001171ae /vendor/lib/egl/libGLESv2_adreno.so (_ZN15EsxRenderBucket20AddUnbucketedEntriesE13EsxCmdBufTypej+397) 12-07 11:00:09.894 31841 31841 F DEBUG : #01 pc 00117417 /vendor/lib/egl/libGLESv2_adreno.so (_ZN15EsxRenderBucket19BucketRenderingCmdsEP21EsxRenderBucketParams+214) 12-07 11:00:09.895 31841 31841 F DEBUG : #02 pc 001305ab /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext19BucketRenderingCmdsEi+586) 12-07 11:00:09.895 31841 31841 F DEBUG : #03 pc 001308c5 /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext21BucketProcessingSetupEv+68) 12-07 11:00:09.895 31841 31841 F DEBUG : #04 pc 000c96d9 /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext14SetQueryIssuedEv+56) 12-07 11:00:09.895 31841 31841 F DEBUG : #05 pc 001159c7 /vendor/lib/egl/libGLESv2_adreno.so (_ZN14EsxQueryObject8IssueEndEv+102) 12-07 11:00:09.895 31841 31841 F DEBUG : #06 pc 000afb61 /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext10GlEndQueryEj+64) 12-07 11:00:09.895 31841 31841 F DEBUG : #07 pc 00cf383b /data/app/com.chrome.canary-2/base.apk (offset 0x4746000)
,
Dec 7 2016
After a fair amount of debugging, I'm starting to once again think that this isn't explicitly a WebVR problem. The reason I say so is that I've stripped all of the actual VR functionality out of the WebVR backend in my local build and had it return nothing but dummy values. Requests to present immediately reject. The GVR API is never initialized. Even with these restrictions in place the Sketchfab app dies when you click the "Enter VR" button (and apparently before it ever actually tries to present VR content.) Based on this it would seem that there is some different code path that Sketchfab is taking when it has (or thinks it has) native WebVR support vs. the polyfill. Something about that path seems to be tickling a driver or command buffer bug on this device. I'll reach out to Sketchfab to see if we can pinpoint what that difference may be. And for the record, I've gotten a different crash stack occasionally as well: 12-07 14:58:28.940 30924 30924 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 12-07 14:58:28.941 30924 30924 F DEBUG : Build fingerprint: 'google/marlin/marlin:7.1/NME60B/3231051:userdebug/dev-keys' 12-07 14:58:28.941 30924 30924 F DEBUG : Revision: '0' 12-07 14:58:28.941 30924 30924 F DEBUG : ABI: 'arm' 12-07 14:58:28.941 30924 30924 F DEBUG : pid: 30566, tid: 30586, name: CrGpuMain >>> org.chromium.chrome:privileged_process0 <<< 12-07 14:58:28.941 30924 30924 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x21 12-07 14:58:28.941 30924 30924 F DEBUG : r0 00000005 r1 00000000 r2 cd3b8adc r3 00000003 12-07 14:58:28.941 30924 30924 F DEBUG : r4 cd3b8a00 r5 d1b85810 r6 00000001 r7 00000000 12-07 14:58:28.941 30924 30924 F DEBUG : r8 00000000 r9 00000000 sl cd3b8a00 fp 00000004 12-07 14:58:28.941 30924 30924 F DEBUG : ip 00001f55 sp edcaef48 lr e23a041b pc e23a01ae cpsr 40070030 12-07 14:58:28.951 30924 30924 F DEBUG : 12-07 14:58:28.951 30924 30924 F DEBUG : backtrace: 12-07 14:58:28.951 30924 30924 F DEBUG : #00 pc 001171ae /vendor/lib/egl/libGLESv2_adreno.so (_ZN15EsxRenderBucket20AddUnbucketedEntriesE13EsxCmdBufTypej+397) 12-07 14:58:28.951 30924 30924 F DEBUG : #01 pc 00117417 /vendor/lib/egl/libGLESv2_adreno.so (_ZN15EsxRenderBucket19BucketRenderingCmdsEP21EsxRenderBucketParams+214) 12-07 14:58:28.951 30924 30924 F DEBUG : #02 pc 001305ab /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext19BucketRenderingCmdsEi+586) 12-07 14:58:28.951 30924 30924 F DEBUG : #03 pc 000c9289 /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext19BindDrawFramebufferEP20EsxFramebufferObject+360) 12-07 14:58:28.952 30924 30924 F DEBUG : #04 pc 000a913d /vendor/lib/egl/libGLESv2_adreno.so (_ZN10EsxContext17GlBindFramebufferEjj+124) 12-07 14:58:28.952 30924 30924 F DEBUG : #05 pc 0008900b /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so 12-07 14:58:28.952 30924 30924 F DEBUG : #06 pc 00072fdb /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so 12-07 14:58:28.952 30924 30924 F DEBUG : #07 pc 0008ce1d /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so 12-07 14:58:28.952 30924 30924 F DEBUG : #08 pc 0005e547 /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so (_ZN3gpu13CommandParser15ProcessCommandsEi+50) 12-07 14:58:28.952 30924 30924 F DEBUG : #09 pc 0005ed33 /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so (_ZN3gpu15CommandExecutor10PutChangedEv+114) 12-07 14:58:28.952 30924 30924 F DEBUG : #10 pc 000fba55 /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so (_ZN3gpu20GpuCommandBufferStub12OnAsyncFlushEijRKNSt6__ndk16vectorIN2ui11LatencyInfoENS1_9allocatorIS4_EEEE+84) 12-07 14:58:28.952 30924 30924 F DEBUG : #11 pc 000fb96f /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so 12-07 14:58:28.952 30924 30924 F DEBUG : #12 pc 000fac4b /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so (_ZN3gpu20GpuCommandBufferStub17OnMessageReceivedERKN3IPC7MessageE+1222) 12-07 14:58:28.952 30924 30924 F DEBUG : #13 pc 0001c5bd /data/app/org.chromium.chrome-1/lib/arm/libipc.cr.so (_ZN3IPC13MessageRouter12RouteMessageERKNS_7MessageE+32) 12-07 14:58:28.952 30924 30924 F DEBUG : #14 pc 000f7d4b /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so (_ZN3gpu10GpuChannel19HandleMessageHelperERKN3IPC7MessageE+34) 12-07 14:58:28.952 30924 30924 F DEBUG : #15 pc 000f7ce5 /data/app/org.chromium.chrome-1/lib/arm/libgpu.cr.so (_ZN3gpu10GpuChannel13HandleMessageERK13scoped_refptrINS_22GpuChannelMessageQueueEE+42) 12-07 14:58:28.952 30924 30924 F DEBUG : #16 pc 0007fc89 /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base5debug13TaskAnnotator7RunTaskEPKcPNS_11PendingTaskE+148) 12-07 14:58:28.952 30924 30924 F DEBUG : #17 pc 000955c1 /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base11MessageLoop7RunTaskEPNS_11PendingTaskE+304) 12-07 14:58:28.952 30924 30924 F DEBUG : #18 pc 00095811 /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base11MessageLoop21DeferOrRunPendingTaskENS_11PendingTaskE+28) 12-07 14:58:28.952 30924 30924 F DEBUG : #19 pc 00095aaf /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base11MessageLoop6DoWorkEv+246) 12-07 14:58:28.952 30924 30924 F DEBUG : #20 pc 00096fe1 /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base19MessagePumpLibevent3RunEPNS_11MessagePump8DelegateE+284) 12-07 14:58:28.952 30924 30924 F DEBUG : #21 pc 00095397 /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base11MessageLoop10RunHandlerEv+50) 12-07 14:58:28.952 30924 30924 F DEBUG : #22 pc 000ac25b /data/app/org.chromium.chrome-1/lib/arm/libbase.cr.so (_ZN4base7RunLoop3RunEv+78) 12-07 14:58:28.952 30924 30924 F DEBUG : #23 pc 003ece5b /data/app/org.chromium.chrome-1/lib/arm/libcontent.cr.so 12-07 14:58:28.952 30924 30924 F DEBUG : #24 pc 00851505 /data/app/org.chromium.chrome-1/lib/arm/libcontent.cr.so 12-07 14:58:28.952 30924 30924 F DEBUG : #25 pc 00850a2b /data/app/org.chromium.chrome-1/lib/arm/libcontent.cr.so (Java_org_chromium_content_app_ContentMain_nativeStart+114) 12-07 14:58:28.952 30924 30924 F DEBUG : #26 pc 00666d8d /data/app/org.chromium.chrome-1/oat/arm/base.odex (offset 0x632000) 12-07 14:58:29.839 30514 30514 W chromium: [WARNING:compositor_view.cc(238)] Child process disconnected (type=9) pid=30566)
,
Dec 16 2016
Ping this is P1 but sitting idle?
,
Dec 16 2016
Yes, Brandon is on leave until January. Klausw@ might be able to pick it up?
,
Dec 16 2016
This is not reproducible on current Chrome Canary. Brandon was working with Sketchfab to get this sorted out. Looks like the sequence of events was: (1) Sketchfab initializes VRDisplay, starts retrieving poses but presentation has not started yet (2) Chrome returns poses (frame data) with a recommended renderWidth=0, renderHeight=0 while not presenting. (See below for why.) (3) Sketchfab resizes the canvas to 0x0 pixels before starting presentation. (4) Issuing GL commands on a 0x0 size canvas seems to trigger pre-existing problems. The usual WebVR idiom is to size the canvas based on recommended renderWidth/renderHeight *after* presentation started in response to a vrpresentchange event. Current Chrome Canary was reporting a 0x0 recommended size while not presenting since for technical reasons it didn't know what size its internal render surface would be before presentation actually started, and it is not able to resize it. While applications can choose to use an arbitrary canvas size, it would always be internally composited onto the fixed-size render surface. The GPU issues seem to be related to drawing on a 0x0 pixel size WebGL canvas and are not specifically WebVR related, as Brandon hand noted above VR presentation wasn't active yet at the time this happened. Dropping to P2 since this appears to be a pre-existing condition, and the workaround was fairly easy once Brandon figured out what was happening. Should this be forked into a new bug for the specific issue of 0x0 WebGL canvas sizes causing GPU issues? FYI, We're changing WebVR to support arbitrary render canvas sizes, side effect of this is that it can consistently report a recommended render resolution even before presentations starts, and it can resize its internal render surface to match whatever size the client's canvas is using.
,
Dec 16 2016
,
Dec 20 2016
If you can reproduce this with a small, self-contained WebGL example not involving WebVR, please file a bug, attach the test case and email me the bug ID. Thanks.
,
Jan 7 2017
This seems unlikely to be resolved in M56, and it sounds like it is no longer reproducible. bajones, what should we do with it?
,
Aug 9 2017
,
Aug 9 2017
,
Aug 24 2017
Brandon, poking as this issue looks like it can be closed off.
,
Oct 16 2017
Based on bug age, temporarily claiming this to investigate and either close or update issue status.
,
Oct 19 2017
One more time, I tried to repro this with Chrome-Dev, and see nothing but happy Sketchfab models. I'm going to close this unless Brandon objects (I'll check with him directly).
,
Oct 19 2017
,
Jul 4
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by bajones@chromium.org
, Dec 7 2016