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 < [email protected]> wrote: > On Wed, Jul 31, 2013 at 2:58 PM, Jason Wilkins > <[email protected]> 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
