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

Re: [Public WebGL] WebGL Best Practices

My take on this is that minimizing the number of WebGL API calls is
still very valid practice.

However, whether achieving minimizing API call counts via caching is a
smart thing to do is a different question. I would argue that reducing
API calls via caching may be a smell of bad design. It is generally
better to design the renderer up front in a way that it avoids
unnecessary API calls in the first place, without needing to impose a

In general if a renderer is designed in a way that the code flow
statically knows what correct state is set at necessary points, it can
avoid making dumb API calls.

When/if that is not possible, I would opt to caching as a last resort.
In such case, I would first see if I could implement the caches at the
highest program logic level possible, before going to the lowest
individual GL call levels.

This way the amount of CPU cycles spent on checking and updating the
caches is minimized.

If we were able to track our way through the GL state submit code all
the way from JS to the browser to the userland driver to the kernel
driver to the hardware, we'd probably see that in every step of the
way, the active GL state is getting cached. I.e. the browser caches
state and does not pass redundant changes to the driver. The driver
caches to avoid expensive userland->kernel transitions and data
marshalling, and the kernel driver caches to avoid unnecessary command
queue population. It is one really well cached API through the pipe -
which is partly why GL is so slow.

Browsers need to validate all WebGL state for security. Being able to
perform proper validation will as byproduct require the browser to
cache a lot of the state, or it will lack the necessary state
information to implement the validation. All of this work adds up,
hence caching in user JS code helps to avoid the overhead from the
validation&caching further down the pipe. The browser caching (and
validation) is your enemy, not a friend.

WebGPU will help with this in the respect that while all sorts of
state tracking will still occur in browsers & drivers, the state
tracking will happen more heavily at cold build stages, rather than
actual hot render call submission stage. Still, I expect it will be
very beneficial to work on minimizing the number of API calls at
render time as much as possible.

ma 25. toukok. 2020 klo 19.09 Andrew Varga (grizzly33@gmail.com)
(public_webgl@khronos.org) kirjoitti:
> That's a really useful page!
> I'm curious of something that is not mentioned here but I came across it many times, eg. in Chapter 9 - Optimizing WebGL Usage of "HTML5 Game Development Insights" and I think many engines follow this practice, which is basically to cache WebGL state in javascript and only actually issue WebGL commands when needed:
> - keeping track of uniforms but only update them before a draw call, and only if their values have changed
> - cache all bindings (active texture unit, buffers, attributes)
> - cache blend states
> - ..etc, basically cache the entire WebGL state to reduce overhead
> Is this still consider a good practice? What I've been wondering is why this cannot be implemented by the browser, if this always makes sense to do?
> And is WebGPU going to be different in this regard?
> Thanks,
> Andrew
> On Fri, Mar 27, 2020 at 6:30 PM Ken Russell (kbr@google.com) <public_webgl@khronos.org> wrote:
>> The investigation is underway in http://crbug.com/1065012 . The native implementation of requestPostAnimationFrame, which is behind the --enable-experimental-web-platform-features flag in Chrome, doesn't exhibit this problem.
>> For the time being, the rPAF polyfill can be used in Firefox, and seems to carry some benefit there.
>> On Fri, Mar 27, 2020 at 9:09 AM Ashley Gullen (ashley@scirra.com) <public_webgl@khronos.org> wrote:
>>> Why doesn't it work well in Chrome? rPAF seems to intuitively make sense once explained. Do you have a link to the discussion?
>>> On Thu, 26 Mar 2020 at 19:52, Ken Russell (kbr@google.com) <public_webgl@khronos.org> wrote:
>>>> Note that there's an active ongoing discussion about the requestPostAnimationFrame best practice. It seems that the polyfill works well in Firefox, but not in Chrome. Suggest holding off adding that to your applications for the moment.
>>>> -Ken
>>>> On Thu, Mar 26, 2020 at 11:40 AM Kai Ninomiya (kainino@google.com) <public_webgl@khronos.org> wrote:
>>>>> The MDN doc links to an explainer:
>>>>> https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md
>>>>> It's pretty small, but it's also not a very complex feature (implementation-wise). As explained there, the original motivation was to allow querying computed DOM properties at a time when it's guaranteed it won't force a relayout.
>>>>> On Thu, Mar 26, 2020 at 5:05 AM Won Chun (won@cbrebuild.com) <public_webgl@khronos.org> wrote:
>>>>>> Are there more resources about requestPostAnimationFrame? First I've heard of rPAF.
>>>>>> -Won
>>>>>> On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr@google.com) <public_webgl@khronos.org> wrote:
>>>>>>> [cross-posted to webgl-dev-list]
>>>>>>> Dear WebGL community:
>>>>>>> Mozilla, with contributions from the rest of the WebGL working group, has just revised the WebGL Best Practices document. It contains a significant number of tips for best structuring WebGL applications and attaining top performance. Please check it out!
>>>>>>> On behalf of the WebGL working group,
>>>>>>> -Ken

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