[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?)



Hmm, yeah, I suppose it'll come down to the performance
characteristics of browser overhead with the cost of Wasm->JS and
security validation vs the emulation overhead.

When I think about emulating
GL_WEBGL_multi_draw_instanced_base_vertex_base_instance and/or
GL_multi_draw, I paint these images in my head where browser would add
overhead to track which shader programs used gl_DrawID, and then
recompile shader programs on the fly on each multi-draw call to inject
gl_DrawID. Or with
GL_WEBGL_multi_draw_instanced_base_vertex_base_instance extension,
keep track of current bindings, create a shadow VAO as a clone of
that, apply the offsets to the shadow clone, and then issue the call.

If the browser emulated these extensions, they would need to be really
really sure that it comes out super-lightweight, or otherwise it can
become detrimental.

It might be really hard to judge if emulating is beneficial or not,
since there does not initially exist WebGL 2 content out there that
would utilize these extensions to be able to provide good
representative measures to profile.

Perhaps the best plan of action might be to first ship the extensions
where natively available, and once there are more content out there
that supply profiling material, use those to benchmark if emulating
will be a win? (and then choose to add wider emulated support if so?)

ti 5. toukok. 2020 klo 19.17 Austin Eng (enga@google.com) kirjoitti:
>
> 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
>> > -----------------------------------------------------------
>> >

-----------------------------------------------------------
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
-----------------------------------------------------------