[Bf-committers] EGL_CONTEXT_LOST and GL_ARB_create_context_robustness

[Jason Wilkins]

I just noticed that there is an extension to EGL to make it behave like
desktop GL.

http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_create_context_robustness.txt

It is probably still worthwhile to make Blender not require this extension
however, depending on how widespread the extension is implemented, and how
many system resources are saved.


On Wed, Jul 31, 2013 at 7:58 AM, 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.
>
> I'm not confident that a lot of the code actually checks right now.  I'm
> not sure, but I feel like I should know since I've been staring at the GL
> code for months, but this isn't something I paid attention too :-)
>
>
>
> On Wed, Jul 31, 2013 at 3:09 AM, Antony Riakiotakis <kalast at gmail.com>wrote:
>
>> I think a good example of that is GPU_free_images that takes care of
>> centrally deallocating all resources and zeroing their identifiers. The
>> design here is that the data structure (image) is the owner (holds the ID
>> resource) of the GPU data so it is easy to invalidate the GPU data for all
>> owners. For shared resources this would not work if the identifier was
>> shared, we need to share an owner that will hold the ID and that owner can
>> be centrally notified for deallocation/zeroing. That means keeping a list
>> of owners of course.
>> I think GPU buffers also have an encapsulating inteface though, possibly
>> shaders too?
>> Note, GPU_free_images also deletes the resources besides zeroing the IDs,
>> I'm not sure if on context loss this is already done, so possibly a
>> version
>> that only zeroes the IDs may need to be written.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>