[PATCH xserver 1/5] glamor: Handle GL_OUT_OF_MEMORY when allocating texture images.

Eric Anholt eric at anholt.net
Thu Nov 19 12:55:01 PST 2015


Pekka Paalanen <ppaalanen at gmail.com> writes:

> On Wed, 18 Nov 2015 09:57:02 -0800
> Eric Anholt <eric at anholt.net> wrote:
>
>> Keith Packard <keithp at keithp.com> writes:
>> 
>> > Eric Anholt <eric at anholt.net> writes:
>> >
>> >> I think it's a safe enough assumption that we're not generating non-OOM
>> >> errors.  And, now that we're logging errors, we should get reports of
>> >> them sooner than we used to.
>> >
>> > Would it be sensible to wrap the glGetError call like this?
>> >
>> > GLenum
>> > glamor_check_gl_oom() {
>> >         GLenum last_oom = GL_NO_ERROR;
>> >         GLenum error;
>> >
>> >         while ((error = glGetError()) != GL_NO_ERROR) {
>> >                 if (error == GL_OUT_OF_MEMORY)
>> >                         last_oom = error;
>> >         }
>> >         return last_oom;
>> > }
>> >
>> > I admit I haven't looked at the Mesa glGetError() implementation, so I
>> > don't know if there's a queue of errors, or just a bitfield.
>> 
>> "When an error is detected, a flag is set and the code is
>> recorded. Further errors, if they occur, do not affect this recorded
>> code. When GetError is called, the code is returned and the flag is
>> cleared, so that a further error will again record its code."
>
> GL ES 2.0 spec explicitly recommends to call it in a loop:
> https://www.khronos.org/opengles/sdk/docs/man/xhtml/glGetError.xml
>
> and GL ES 3.2:
> https://www.khronos.org/opengles/sdk/docs/man32/html/glGetError.xhtml
>
> and OpenGL 4.5 also:
> https://www.opengl.org/sdk/docs/man/html/glGetError.xhtml
>
> My vague recollections are from OpenGL 2.1 era and already then you
> called it in a loop until it cleared to be sure.

I remember writing the loop in other code, but the Mesa implementation
only stores a single error.

I still stand by "If we've got other GL errors happening before this
point, we're already totally screwed, and you should go figure out where
they're coming from"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20151119/6e13fd46/attachment.sig>


More information about the xorg-devel mailing list