[Public WebGL] WEBGL_lose_context

Andrew [email protected]
Fri Jan 27 00:42:52 PST 2017


I was a bit surprised to learn that the resources on the GPU are freed up
by the browser when their JS objects are GC'ed, I thought you needed to
call for example deleteTexture explicitly.

So what happens if I have a very simple demo where I just create a texture,
upload some image onto it, I lose the reference for the JS object (the
WebGLTexture instance) but I still have a render loop where the shader I'm
rendering with uses that texture?
In this case I thought since I no longer need to do anything to that
texture with JS (after I bind it once initially to a given unit), I'm free
to lose it's WebGLTexture reference but since I haven't deleted the
resource on the GPU, I can still use it for rendering.
Instead of this, when the GC collects the WebGLTexture reference and frees
up the resource on the GPU, there will be a WebGL warning/error because I'm
trying to use a texture which has been deleted?



On Fri, Nov 11, 2016 at 11:55 PM, Jeff Gilbert <[email protected]> wrote:

>
> To be clear, while we do guarantee that unreferenced WebGL objects
> will eventually be GC'd, like with all GC-able objects, do not expect
> it to be prompt. For instance, Firefox (at least) does not trigger GC
> to address a high-GPU-memory situation, so relying heavily on the GC
> to release GPU-memory-intensive WebGL resources is an anti-pattern,
> and could lead to OUT_OF_MEMORY issues.
>
> On Fri, Nov 11, 2016 at 2:23 PM, Maksims Mihejevs <[email protected]>
> wrote:
> > Thank you Russell and Jeff.
> >
> > In PlayCanvas we do encourage users to release resources associated with
> > abstract assets in order to manage their data on GPU.
> > Few months back when we made changes on engine to enable clear deleting
> of
> > resources. Before that, despite assumption that some stuff would be
> GC'ed,
> > it was actually complex to debug, and seemed like wasn't a case.
> > So now users can easily release GPU resources by explicit calls.
> >
> > Thanks for clarification.
> > Max
> >
> > On 11 November 2016 at 02:30, Kenneth Russell <[email protected]> wrote:
> >>
> >> Max: not to speak for Jeff, but while that will work, it is strongly
> >> discouraged. There is no guarantee that the WebGLTexture object will be
> >> reclaimed promptly be the garbage collector. Please use the explicit
> delete*
> >> APIs on the WebGLRenderingContext to release GPU resources that your
> >> application is no longer using.
> >>
> >> -Ken
> >>
> >>
> >> On Thu, Nov 10, 2016 at 6:22 PM, Maksims Mihejevs <[email protected]>
> >> wrote:
> >>>
> >>> So Jeff, this should work?
> >>>
> >>> var texture = gl.createTexture()
> >>> // put buffer, and upload it to GPU
> >>> texture = null;
> >>> // after some time that texture will be collected by GC?
> >>>
> >>> Cheers,
> >>> Max
> >>>
> >>> On 10 November 2016 at 22:02, Jeff Gilbert <[email protected]>
> wrote:
> >>>>
> >>>> There's no way to know from JS that a GL object is unused, but we do
> >>>> track the WebGL JS objects and GC them when they are unused by both JS
> >>>> and GL. (GL resources are freed when we GC them)
> >>>>
> >>>> It's not a clean solution, but WEBGL_lose_context does give you a way
> >>>> to very strongly hint to the browser that you want it to delete all a
> >>>> WebGL context's resources. (Certainly in Firefox, loseContext()
> >>>> destroys all child objects of the context, then tears down the actual
> >>>> driver's GLContext as well)
> >>>>
> >>>> In fact, when there are too many outstanding WebGL contexts active in
> >>>> the browser (maybe many background tabs?), our method for controlling
> >>>> resource usage is to force the oldest WebGL context to become Lost.
> >>>> The code path used here is identical in Firefox to what's invoked by
> >>>> `loseContext()`.
> >>>>
> >>>> I'm not sure what the codepaths look like in other browsers, but
> >>>> `loseContext()` is a byword for "release this context and its
> >>>> resources" in Firefox.
> >>>>
> >>>> On Tue, Nov 8, 2016 at 3:39 PM, Maksims Mihejevs <[email protected]>
> >>>> wrote:
> >>>> > GPU resources have to be explicitly destroyed, as there is no way to
> >>>> > know
> >>>> > from browser if it is no more needed. Because references are simply
> -
> >>>> > Number.
> >>>> >
> >>>> > If developer uploads texture to GPU, the only way to remove it, is
> by
> >>>> > calling deleteTexture.
> >>>> > There is no persistent object in JavaScript associated with GL
> >>>> > references.
> >>>> >
> >>>> > It is not poor design of WebGL, but just inherited design from
> OpenGL
> >>>> > ES.
> >>>> > Which not sure if anyone anticipated, that would be used not only in
> >>>> > static
> >>>> > environments, but in such dynamic as browser.
> >>>> >
> >>>> > Perhaps good way of destroying context with releasing all associated
> >>>> > resources could be exposed to WebGL, especially with the nature of
> >>>> > single-page websites.
> >>>> >
> >>>> > I assume it does it when you remove canvas element from DOM and GC
> all
> >>>> > related to context data. Making sure it is not referenced anywhere
> in
> >>>> > JS.
> >>>> >
> >>>> > Cheers,
> >>>> > Max
> >>>> >
> >>>> >
> >>>> > On 8 Nov 2016 5:22 p.m., <[email protected]> wrote:
> >>>> >
> >>>> > Well it’s a dirty trick for sure, and I wouldn’t recommend it to
> >>>> > anyone :)
> >>>> >
> >>>> >
> >>>> >
> >>>> > -          Omar
> >>>> >
> >>>> >
> >>>> >
> >>>> > From: Justin Novosad
> >>>> > Sent: Tuesday, November 8, 2016 6:58 PM
> >>>> > To: [email protected]
> >>>> > Cc: Jukka Jylänki; [email protected]
> >>>> >
> >>>> >
> >>>> > Subject: Re: [Public WebGL] WEBGL_lose_context
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Tue, Nov 8, 2016 at 10:45 AM, <[email protected]> wrote:
> >>>> >
> >>>> > I’ve added WebGL context to the iframe element and then found out
> that
> >>>> > refreshing that iframe page resulted in significant memory decrease
> in
> >>>> > Chrome as I watched it using dev tools (garbage collection kicking
> >>>> > in?). As
> >>>> > far as I know, this is the only way of “deleting” WebGL context on
> >>>> > Chrome
> >>>> > (but I am still not sure as I’m not aware of what Chrome is actually
> >>>> > doing)
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > Hmmm... you need to determine whether that trick relies on specified
> >>>> > behaviors.  Otherwise, this may very well be a trick that works
> today
> >>>> > but
> >>>> > not tomorrow.  Anyone here an iframe expert?
> >>>> >
> >>>> > -          Omar
> >>>> >
> >>>> >
> >>>> >
> >>>> > From: Jukka Jylänki
> >>>> > Sent: Tuesday, November 8, 2016 6:19 PM
> >>>> > To: Ryan Patterson
> >>>> > Cc: Kenneth Russell; public webgl
> >>>> > Subject: Re: [Public WebGL] WEBGL_lose_context
> >>>> >
> >>>> >
> >>>> >
> >>>> > I agree and have myself sometimes pondered about how to kill a
> context
> >>>> > explicitly, and there's no way other than to release refs to all GL
> >>>> > objects
> >>>> > and leave it to the GC. It would be nice to have an explicit API,
> >>>> > although
> >>>> > the lose_context extension is not it (and shouldn't be), because it
> >>>> > matches
> >>>> > the resource loss semantics from the system, to solve another
> problem,
> >>>> > and
> >>>> > not the context itself. It would be nice to have a deleteContext()
> >>>> > feature,
> >>>> > since otherwise getContext()ing something effectively "taints" the
> >>>> > <canvas>
> >>>> > and ties it to that context type for its remaining lifetime, which
> is
> >>>> > a bit
> >>>> > messy. Not critical, but agree this is a bit dirty part if the API.
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Nov 7, 2016 4:24 PM, "Ryan Patterson" <[email protected]>
> wrote:
> >>>> >
> >>>> > Unfortunately I have been unable to find the deleteContext function
> in
> >>>> > the
> >>>> > canvas API.  Some implementations keep webGL contexts around even
> >>>> > after all
> >>>> > references are set to null.  The WEBGL_lose_context extension seems
> to
> >>>> > be
> >>>> > the only way to declare you are finished with a context and free the
> >>>> > context
> >>>> > resource itself in a deterministic manor.
> >>>> >
> >>>> > _____________
> >>>> > Ryan Patterson
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Fri, Nov 4, 2016 at 1:45 PM, Kenneth Russell <[email protected]>
> >>>> > wrote:
> >>>> >
> >>>> > This deliberately isn't specified. If you're looking for a way to
> free
> >>>> > your
> >>>> > application's resources, you should use the various delete* APIs.
> >>>> >
> >>>> >
> >>>> >
> >>>> > -Ken
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Fri, Nov 4, 2016 at 10:28 AM, <[email protected]> wrote:
> >>>> >
> >>>> > It says the extension “WEBGL_lose_context” simulates webgl context
> >>>> > loss.
> >>>> > Does it mean the browser actually frees the resources on the GPU
> >>>> > allocated
> >>>> > by the webgl context or just pretends that it did?
> >>>> >
> >>>> >
> >>>> >
> >>>> > -         Omar
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>
> >>>
> >>
> >
>
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170127/f9064b76/attachment.html>


More information about the public_webgl mailing list