[Bf-committers] EGL_CONTEXT_LOST and GL_ARB_create_context_robustness

[Jason Wilkins]

It is difficult to answer these questions right now since I'm not
completely familiar with where the original pixel data is kept.

By "acquire the resource", I mean generate an ID and then set it to the
state that is needed. So for textures it would mean generating a texture
ID, loading the pixels, and then setting up the texture properties.

And yes, it is a problem if GPUtexture doesn't contain enough information
to recreate the texture.  I actually ran into this problem with the shader
export function when porting it to ES.  ES does not allow you to read the
texture data (it doesn't save a copy).  As a quick fix I save that data in
the GPUtexture so that it can be copied.  (With the intention that I
revisit that code later for a better solution).

If we do not want to save pixel data for every GPUtexture then we need a
callback function that understands how to reload the data from disk or
regenerate it procedurally.  Then that function could be used to reacquire
the texture, instead of the brute force method of saving the pixels.

Note that desktop OpenGL already has to keep this data around, so it isn't
like saving this data on ES is using "extra" memory.  It is memory that is
already wasted on the desktop.

If we get this working on ES however, we could use the desktop version of
this extension and stop wasting that memory if we use "smart" functions
that reacquire textures by loading them from disk or recompute them.




On Wed, Jul 31, 2013 at 11:27 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> I suppose you could clear the zeros and then have some
> GPU_texture_lost(..) or GPU_shader_lost(..) functions that checks
> them, so that you have code like this? If you don't free the entire
> thing you have to write extra code to reconstruct the texture or
> shader, easier is just to free it entirely and recreate.
>
> if (!ima->gputexture || GPU_texture_lost(&ima->gputexture)) // will
> free the entire GPUtexture if it was lost
>      ima->gputexture = GPU_texture_create(..)
>
> ... use texture ...
>
>
> But maybe I'm misunderstanding, what does "reacquiring the resource"
> mean? Aren't the actual texture pixels or shader lost? So then the
> wrapper can't really recreate it on behalf of the owner, only the
> owner knows how to create this data.
>
>
> On Wed, Jul 31, 2013 at 5:43 PM, Jason Wilkins
> <jason.a.wilkins at gmail.com> wrote:
> > I'm not sure I follow.  Why would a higher level wrapper need to be freed
> > entirely?  Couldn't it reacquire the resource on behalf of whoever is
> using
> > it?
> >
> >
> > On Wed, Jul 31, 2013 at 9:38 AM, Brecht Van Lommel <
> > brechtvanlommel at pandora.be> wrote:
> >
> >> On Wed, Jul 31, 2013 at 2:58 PM, Jason Wilkins
> >> <jason.a.wilkins at gmail.com> wrote:
> >> > I'd rather centralize the zeroing out so it isn't ad-hoc.  It could
> be as
> >> > simple as a gpuGenTextures that returns GLuint* instead of GLuint.
>  Then
> >> > all that is needed is a std::vector of GLuint held in a central
> location
> >> > that can be zeroed out when there is a context loss.
> >> >
> >> > The owner of a resource should restore it if it is zero and if
> something
> >> > isn't the owner it should maybe skip whatever it was doing if it finds
> >> the
> >> > resource missing (it will probably be there next frame).
> >> >
> >> > If it is a problem for resources with multiple owners to pass the
> buck on
> >> > restoring it, then maybe a pseudo owner should be made that is
> guaranteed
> >> > to restore it if it is missing, and do so before anybody else needs
> it.
> >>  Or
> >> > maybe I'm naive and this needs some kind of dependency graph...  I
> doubt
> >> it.
> >> >
> >> > Some type safety could be added by putting the IDs in a struct.
> >> >
> >> > struct GPUtexID { GLuint* texID; };
> >> > struct GPUvboID { GLuint* vboID };
> >> > etc.
> >> >
> >> > Then you have gpuGenTextures(GLuint n, GPUtexID* idOut);
> >> >
> >> > I don't think the problem is centralizing the zeroing out process.  I
> >> think
> >> > the problem is making sure all the code that uses resource is ready to
> >> > restore it.
> >>
> >> This is why I think it should be a higher level thing than wrapping
> >> the OpenGL functions. We already have some higher level wrappers for
> >> OpenGL data and they would need to be freed entirely, I think we
> >> should build things at that level, zeroing out ids is not enough.
> >>
> >> Brecht.
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>