[Bf-committers] EGL_CONTEXT_LOST and GL_ARB_create_context_robustness

Jason Wilkins jason.a.wilkins at gmail.com
Wed Jul 31 17:43:23 CEST 2013


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
>


More information about the Bf-committers mailing list