[Public WebGL] WEBGL_lose_context

Zhenyao Mo [email protected]
Fri Jan 27 09:02:35 PST 2017


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/20170127/0ced278b/attachment.html>


More information about the public_webgl mailing list