WebGL_multi_draw beware of incosistency!

[Ivan Popelyshev]

this commit helped us a lot: https://github.com/sciner/webcraft/pull/236/files

This function likes Int32Array offset:  https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_multi_draw/multiDrawElementsWEBGL 

However this one has one of params Uint32Array : https://registry.khronos.org/webgl/extensions/WEBGL_multi_draw_instanced_base_vertex_base_instance/

It just happens that when we use it, offsets in regular multidraw are base instance offsets in our project. It added 7% JS perf to our main thread, found it by profiling.

Maybe we have to add important notice somewhere in MDN?

Ivan.

[Ken Russell]

Hi Ivan,

Thanks for highlighting that to the community! It's unfortunate that the typed arrays are silently (and expensively) converted - it would be better if a TypeError were raised, but that would be illegal according to Web IDL.

Have filed https://github.com/KhronosGroup/WebGL/issues/3506 about adding a non-normative note to the extension specifications themselves.

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/f153b2b6-9cd0-490e-af1d-104e8d7cbdffn%40googlegroups.com.

[Kai Ninomiya]

And for MDN, you can contribute a change yourself :) Click "Edit on GitHub" at the bottom and you can open a GitHub PR.

-Kai (he/they)

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2d16RYM4EbsDhaswt%2B1z8YpoT59500kJJ3dtyFceys%2BoA%40mail.gmail.com.

[Pawel Misiurski]

I noticed that webgl doesn't complain about non-typed arrays [] being passed to webgl API where typed arrays are expected. There are no errors or warnings. Is there also a silent and expensive conversion happening in these cases or is it solved differently and non-typed arrays don't have any extra overhead?

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CANxMeyAfOrStgVyG9r5cAf60N8WOJmD7Xd9%3DqNxJoMEtR-HEzg%40mail.gmail.com.

[Ken Russell]

Where do you see this behavior specifically? Some of the data upload APIs, like uniform*fv and uniform*iv, deliberately use the Float32List and Int32List typedefs in order to accept both typed arrays and ordinary JavaScript arrays.

https://registry.khronos.org/webgl/specs/latest/1.0/

https://registry.khronos.org/webgl/specs/latest/2.0/

It shouldn't be possible to pass in JavaScript arrays to APIs specifically taking an ArrayBuffer or ArrayBufferView, like readPixels or texImage*.

-Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAL5jOFHtmnhYK2-xN26CPsrB6dV%2BJKtgami9xQe3fVivQUwZWQ%40mail.gmail.com.

[Pawel Misiurski]

yes, that's in uniform upload. These are usually in the hottest place of the rendering loop so I'm trying to choose the best strategy. In JS non-typed arrays are faster than typed(at least in V8)). Given an object with some properties i.e. position(vec3) and matrix (mat4x4) that are being pushed as uniforms, which will be the best choice:
A) Always operate on typed arrays that will be pushed to uniforms - slower operations in JS (read/write, multiplying matrices etc)

B) Operate on non-typed arrays and copy to temp typed just before pushing uniforms - cost of copying on each uniform upload before every drawcall

C) Only operate on non-typed arrays and directly push them as uniforms - hidden conversion cost(if there is any) about which I'd like to know more

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2cuAjtBV-y-QO6aXkv13R--KS2uswx9jjoP82awgx70KQ%40mail.gmail.com.

[Ken Russell]

It's hard to know without measuring things but (A) sounds like the best choice. If you are seeing significant performance differences between typed arrays and JS arrays then please write a small benchmark and file a bug on https://crbug.com/v8 (and feel free to post the bug ID here). Note that typed array allocation is unfortunately slower than JS array allocation, and I think that's true across multiple JS engines. However, operations on them - in particular Float32Arrays representing matrices and vectors - should be fast.

You might also look into https://glmatrix.net/ which has been performance tuned by members of the community for a number of years.

-Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAL5jOFGmE_RazKjBCGTUDFSJ1r%2B_9kNvcjRtir4CNNGRiu47xw%40mail.gmail.com.

[Pawel Misiurski]

Thanks for your help, as always the best is to benchmark. Glmatrix is very good too

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2cT8K17QQKE9%2BRuzmPjVRi1243XyH1XkOcbd9shgnR8sg%40mail.gmail.com.