--disable-gpu-compositing seems to disable WebGL |
|||
Issue descriptionAttached is my about-gpu with --disable-gpu-compositing. It says WebGL is enabled, but visiting http://get.webgl.org/ says WebGL is not available, as does visiting the WebGL CTS. It's important to be able to disable GPU compositing for developers who are trying to diagnose bugs with WebGL content. Without disabling compositing, it becomes very hard to get a relevant command stream capture, since so many of the GPU commands are dealing with compositing. I'm having a hell of a time just diagnosing a bug ( issue 594509 ) because I can't seem to get a frame capture and figure out what's happening. It would be a good help if I could disable GPU compositing.
,
Mar 23 2016
Sorry for the difficulty. Have you tried using a user-level tool like https://benvanik.github.io/WebGL-Inspector/ to capture just the WebGL calls? I think it will be difficult to eliminate the browser's use of OpenGL entirely.
,
Mar 23 2016
I've never managed to get the WebGL inspector to work successfully, unfortunately. The --disable-gpu-compositing flag used to work at one point.
,
Mar 23 2016
I think jmadill@ may be interested in stepping through the actual native calls with a graphics debugging tool. The WebGL command stream isn't helpful there (and can often differ from the resulting OpenGL ES command stream given to ANGLE in any case). FWIW, if the issue you're trying to track down reproduces in Firefox (you may need to drop ANGLE binaries in for more recently introduced issues, as they update versions more slowly), assuming it hasn't moved to using ES for compositing since the last time I was actually debugging WebGL issues, it can be significantly easier to debug isolated WebGL-over-ANGLE issues there.
,
Mar 23 2016
Thanks Shannon, I had forgotten about the trick with Firefox. I was able to get that working and that gives me a few more things to try.
,
Jan 19 2017
I'm afraid this is by design. Our WebGL implementation doesn't have the necessary read-back path to composite the output in software.
,
Jan 19 2017
That's kinda unfortunate. Was this a change at some point? It used to work. Also means that for some WebGL debugging, Firefox is superior to Chrome, and Chrome developers are forced to use Firefox to work.
,
Jan 19 2017
Actually, this seems to work again. So not sure what's up.
,
Jan 19 2017
It should use swiftshader if it can when this flag is present, and do a readback from that to a bitmap for the compositor.
,
Jan 19 2017
> Also means that for some WebGL debugging, Firefox is superior to Chrome, and Chrome developers are forced to use Firefox to work. Curious what is better when compositing is disabled. Just less noise in the GL driver?
,
Jan 19 2017
Yes, except the noise makes it very difficult (I'd say practically impossible) to debug WebGL via the CTS with ANGLE. I don't think it's using swiftshader right now, so I'm happy!
,
Jan 19 2017
Oh I see. I guess when you pass it by hand it doesn't cause swiftshader. Interestng, thanks
,
Jan 19 2017
Interesting. Do we do the readback in that mode then? |
|||
►
Sign in to add a comment |
|||
Comment 1 by kbr@chromium.org
, Mar 23 2016