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

Re: [Public WebGL] context loss, slowdowns and aw-snap dialogs



Determining the amount of available "video memory" is an ill-defined
problem. Some GPUs have different memory pools for different object
types, and some use unified memory architectures. Some operating
systems deal better with paging resources off the GPU than others. The
WebGL working group has asked GPU vendors on multiple occasions to
define APIs to query the amount of video memory identically across
GPUs, but there has been no success. Sorry there isn't a better
solution, but I recommend defining some sort of heuristic like "use
100 bytes of video memory per pixel" and scale your application's
buffer and texture usage appropriately. As far as I know, Google Maps
uses such a heuristic and it works pretty well across a range of
devices, since mobile devices with less available video memory also
tend to have proportionately smaller screens.

-Ken



On Thu, Apr 23, 2015 at 10:19 AM, Florian Bösch <pyalot@gmail.com> wrote:
> When allocating resources via WebGL there is a point at which you will
> experience dramatic slowdowns in rendering performance due to virtualization
> of vram to ram (in some instances) and sometimes even to page-swap.
>
> Likewise, if a sudden context loss is experienced while a user is operating
> the app, it's often the case that some unseen boundary of ram has been
> stepped over.
>
> Sometimes these context losses can take the GPU process with them, and
> you'll get aw-snap dialogs, sometimes you'll get those despite the GPU
> process chugging along.
>
> Recovering mid-run from a context loss is a harrowing experience. Morever it
> is likely that trying to do so will end up in hysteresis because in
> restoring the resources that caused the context loss, another context loss
> will be provoked.
>
> Dealing with slowdowns of unknown origin can be difficult, because you don't
> know if a given UA/machine is running slow because it is just slow for other
> reasons, or if it's running slow because you caused virtualization to ram or
> page-swap.
>
> From this it is fairly clear that the situation we find ourselves in is not
> conductive to a smooth user-experience. It is therefore absolutely mandatory
> that a cross-vendor way be introduced to detect how much vram you can
> consume before you will experience slowdowns, virtualizations, page-swaps,
> context losses, aw-snaps and GPU process crashes.
>
> Shotgunning everything at the vram wall and dealing with the carnage when it
> happens is not a sustainable way to go about writing reliable, fast,
> responsive and performant applications.

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