User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150331030204 Steps to reproduce: There seems to be a performance regression in DrawElementsInstanced if the instancing buffer is dynamically updated with glBufferSubData. To reproduce: - on a Windows7 machine: - in FF Nightly v40: - go here: http://floooh.github.io/oryol/Instancing.html - note how the timer for 'draw' is always above 2ms - close FF Nightly, and do the same in regular FF 36 - note how the 'draw' timer is much lower (around 0.2..0.3ms) This is an emscripten demo. Also note that when the dynamic instance buffer update is disabled by left clicking into the canvas, the DrawElementsInstanced is much faster in Nightly, so the problem seems to be related to glBufferSubData. I encountered a similar problem in Chrome a long while ago which led to this discussion: https://groups.google.com/forum/#!searchin/webgl-dev-list/floooh/webgl-dev-list/vMNXSNRAg8M/lu1NkJ22J_YJ Relevant source code pointers: render loop: https://github.com/floooh/oryol/blob/ff56e6ec85af8ff76d182763272e298173f7b345/code/Samples/Gfx/Instancing/Instancing.cc#L50 vertex data update with double buffering: https://github.com/floooh/oryol/blob/ff56e6ec85af8ff76d182763272e298173f7b345/code/Modules/Gfx/gl/glRenderer.cc#L825 DrawInstanced wrapper: https://github.com/floooh/oryol/blob/ff56e6ec85af8ff76d182763272e298173f7b345/code/Modules/Gfx/gl/glRenderer.cc#L785
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6f49eb8f1ee0&tochange=a790927adb60 webgl.angle.try-d3d11 = false helps.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf, regression
Version: 40 Branch → 37 Branch
How does the performance compare to Chrome with D3D11 enabled and disabled?
timing in Chrome Canary which runs on D3D11 by default are shuffeled around but still much faster. The BufferSubData update takes around 0.5ms at 100k particles, and the draw is very fast (less then 0.05ms). On FF the buffer update seems to be deferred to the draw call, but is much slower in FF nightly (>2ms vs. 0.5ms). Not sure how much this might be off since Chrome is rendering in a different process. Of course this could also be the case in FF, that the problem was always there, but in some part of the frame I am not measuring. BUT: The timing in FF40 is also very erratic, jumping between 2 and 5ms, which is extremely slow for what should be straight copy of vertex data. The rendering also starts to stutter earlier in FF40 vs. older FF or Chrome Canary. I remember that some sort of vertex index validation kicks in even if only updating vertex data (FF had some sort of advanced dirty range detection compared to Chrome), but this is probably 2 years back. Just speculation though. If it would be a CPU/GPU sync problem I would expect that there's some >16ms delay (the current demo uses double buffering for the dynamic data to help on non-WebGL platforms, I think this doesn't matter at all in WebGL).
Erm, maybe I'm blind but I'm not finding any option in Chrome's about:flags or about:gpu to switch back to the d3d9 backend...
(In reply to Andre Weissflog from comment #4) > Erm, maybe I'm blind but I'm not finding any option in Chrome's about:flags > or about:gpu to switch back to the d3d9 backend... You need to add --disable-d3d11 to the command line
I did a test with Chrome Canary using the d3d9ex backend (verified in about:gpu) and I'm not seeing a difference in the reported timings or 'subjective smoothness' compared to the d3d11 backend.
Does this still reproduce?
Summary: WebGL DrawElementsInstanced/BufferSubData Perf Regression in FF Nightly 40 vs FF 36 → WebGL DrawElementsInstanced/BufferSubData performance regressed in Firefox 37
The url in comment #0 is no longer available. Instead, tested with http://floooh.github.io/oryol/asmjs/Instancing.html I can reproduce the problem on 40.0.3. However, I cannot reproduce the problem on Windows10 45.3.0ESR and Nightly52.0a1.
(In reply to Alice0775 White from comment #8) > The url in comment #0 is no longer available. > Instead, tested with http://floooh.github.io/oryol/asmjs/Instancing.html > > I can reproduce the problem on 40.0.3. > However, I cannot reproduce the problem on Windows10 45.3.0ESR and > Nightly52.0a1. Great, thanks.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.