[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] State of WEBGL_draw_instanced_base_vertex_base_instance? (and WEBGL_multi_draw + WEBGL_multi_draw_instanced_base_vertex_base_instance?)



Hi Jukka,

That's great feedback that the multi draw path could be potentially slower than the non-multi draw path.

At the time, Chrome's implementation of WEBGL_multi_draw is indeed emulated as we found that emulating
versus using an extension such as GL_EXT_multi_draw_arrays had the same performance. i.e. the driver
is probably also emulating. Nevertheless, we found performance to be much, much faster using the
WEBGL_multi_draw extension because of the significantly reduced validation and command serialization overhead.
One customer has reported to us 15% CPU time reductions in their application from using the extension.

Note that there is no VAO/VBO rebinding with WEBGL_multi_draw, though there is manual setting of a
uniform for gl_DrawID (if used in your shader).
With GL_WEBGL_multi_draw_instanced_base_vertex_base_instance, I do believe the base_vertex_base_instance
aspect may be emulated on some platforms. Shrek would know more about the details of the implementation.
Based on your feedback we should consider not emulating the baseVertex and baseInstance.

Cheers,
Austin


On Mon, May 4, 2020 at 11:42 PM Jukka Jylänki <jujjyl@gmail.com> wrote:
Shrek, I'll try to debug more and get confidence that I am doing
everything right in the test, and submit a bug if not.

Jeff, multi_draw is useful for improving batching of unique meshes. I
hope that browsers should *not* in any circumstances emulate
multi_draw support, because that would be counterproductive. Dynamic
batching renderers may have both a multi_draw path, and a
non-multi_draw path (similar to instancing and non-instancing paths in
dynamic instancing renderers), and they will take a feature test to
see if multi_draw is supported, and use that if it is, but use the
non-multi_draw path if not.

If browser emulated multi_draw with a manual GL uniform and a loop of
offseted VBO/VAO re-binds + regular draws, it would probably be much
slower than the original non-multi_draw path that the renderer would
have. That would be catastrophic to WebGL performance for the
application on systems where the GL driver did not natively support
multi_draw.

Hence I hope that browsers would never advertise multi_draw (or
base_vertex/base_instance) support whenever that support is not
natively enabled by the underlying GL driver, because that would
prevent the page from taking its straightforward fallback approach.

ma 4. toukok. 2020 klo 22.04 Jeff Gilbert (jgilbert@mozilla.com)
(public_webgl@khronos.org) kirjoitti:
>
>
> I would love to hear more about what you hope to get out of multidraw!
> In most cases, multidraw will be emulated within the WebGL engine, and
> you can emulate it yourself from userland if gl_DrawID is what you
> want. (Many implementations will be polyfilling this functionality via
> a builtin uniform IIRC) The WebGL WG is interested in multidraw it
> that it reduces JS<->C++ boundary crossings. (This seems to be
> particularly expensive for Chrome iirc) Multidraw will allow batching
> from the app to the WebGL engine, but this won't generally batch all
> the way to the driver. I expect it to be useful where WebGL-engine
> draw call overhead is high, which hasn't been the case in most
> profiles I've seen of Firefox, at least. (A couple percent at most)
>
> On Fri, May 1, 2020 at 1:07 PM Shrek Shao (shrekshao@google.com)
> <public_webgl@khronos.org> wrote:
> >
> > Hi Jukka
> >
> > It's great to hear that you find it useful. Making base_vertex_base_instance and multidraw public in chrome is within our plan list for this cycle. We are willing to work with you to accelerate pushing forward the extension implementation.
> >
> > About the scale test corruption on windows, could you share more information about the test?
> > We recently fixed a known issue for basevertex indexRange for DYNAMIC_DRAW attributes on windows D3D11 backend https://chromium.googlesource.com/angle/angle/+/d9268889181c422ac3ccb2ad97179ab7f9dac06f. Wondering if this commit is included in the build you used for testing.
> >
> > Thanks,
> > Shrek
> >
> > On Fri, May 1, 2020 at 2:18 AM Jukka Jylänki (jujjyl@gmail.com) <public_webgl@khronos.org> wrote:
> >>
> >>
> >> Hi all,
> >>
> >> I was wondering what the most recent status of
> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_draw_instanced_base_vertex_base_instance/
> >> is?
> >>
> >> Recently it came up that it'd be super useful for optimizing rendering
> >> in a packed vertex buffers context. Tried it out, and observed
> >>
> >> 1. Supported in Chrome Canary behind experimental chrome://flags setting.
> >>
> >> 2. Not supported in Firefox Nightly (or Safari since no WebGL 2).
> >>
> >> 3. Not supported in Chrome on macOS, only on Windows. (Linux not tested)
> >>
> >> 4. Looking at GitHub repository, most recent update is ~6 months ago:
> >> https://github.com/KhronosGroup/WebGL/tree/master/extensions/WEBGL_draw_instanced_base_vertex_base_instance
> >>
> >> 5. In a small scale test on Chrome Canary on Windows with Emscripten,
> >> I unfortunately run into corrupted rendering with
> >> WEBGL_draw_instanced_base_vertex_base_instance. :( Same code compiled
> >> to a native Windows app works ok though, so scratching my head if I'm
> >> screwing something up or if there might be an implementation bug. (the
> >> conformance test
> >> https://www.khronos.org/registry/webgl/sdk/tests/conformance2/extensions/webgl-multi-draw-instanced-base-vertex-base-instance.html?webglVersion=2&quiet=0&quick=1
> >> does pass though)
> >>
> >> It would be really cool to get adoption for this in to WebGL 2 in
> >> different browsers (and WEBGL_multi_draw and
> >> WEBGL_multi_draw_instanced_base_vertex_base_instance as well!).
> >>
> >> Multi-draw would be a really big deal due to its gl_DrawID support
> >> (indexing large packed UBOs with gl_DrawID enables heavy batching
> >> opportunities), and base_vertex/base_instance likewise enables great
> >> opportunities to batch buffer uploads to a single buffer, to get to
> >> some of the AZDO goodness perhaps "already today" while waiting for
> >> WebGPU.
> >>
> >> Cheers,
> >> Jukka
> >>
> >> -----------------------------------------------------------
> >> You are currently subscribed to public_webgl@khronos.org.
> >> To unsubscribe, send an email to majordomo@khronos.org with
> >> the following command in the body of your email:
> >> unsubscribe public_webgl
> >> -----------------------------------------------------------
> >>
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>