[Public WebGL] WEBGL_lose_context

Andrew [email protected]
Sat Jan 28 04:49:06 PST 2017


That makes sense, thank you!

On Fri, Jan 27, 2017 at 6:02 PM, Zhenyao Mo <[email protected]> wrote:

>
>
> On Fri, Jan 27, 2017 at 12:42 AM, Andrew <[email protected]> wrote:
>
>> 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 that case, that texture must be bound to a binding point, which is a
> reference to keep the object alive.
>
>
>> 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/20170128/54ee31ed/attachment.html>


More information about the public_webgl mailing list