Gracefully handling different tiers of GPU & context lost

So we have an application that is fairly demanding, now this presents a couple of problems which seems close to impossible to solve in THREE, but in fact it’s probably more the fault of webgl.

Ideally we’d like to poll for hardware info & make a decision from that, but sadly something as rudimentary as even how much VRAM the device supports is out of reach. Consequently it would seem the only approach possible is to try for the high end mode and see if it fails during initialization. Now sadly it’s extremely common with integrated intel GPUs, and those can have some seriously low amounts of VRAM assigned to them. What happens when you go beyond that limit isn’t, as one would expect, that you get an out of memory error, no instead it seems to throw a context lost.

Now the problem is inside that context lost handler you have no idea if it’s one of 2 very different problems. For the normal problem where it’s actually other tabs / programs which are infringing on the GPU resources the user should actually close those other ones down & cross their figures waiting for a context restore event, in which case we can gracefully recover. But it’s just as likely that the error is actually the first one mentioned. In that case we give the user an option to be redirected to the light weight version. Sadly in Chrome this strategy doesn’t work, because a tab which has experienced a context lost can’t ever create a new context, even though the card is fully capable of running this light weight version. Redirecting / reloading via javascript does nothing at all, context creation always fails. Essentially I’m wondering if I’m going about things the right way, how do others handle these issues with context lost & scaling your app depending on GPU?

Have you seen the detect-gpu package?

1 Like