Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
On 28.03.2017 22:37, gregory hainaut wrote: On Mon, 27 Mar 2017 16:10:32 +0200 Gregory Hainaut wrote: Hello, Sorry I was in vacation. I will update my patch with a hash map to trace buffer creation/destruction. Cheers, Gregory On 3/20/17, Nicolai Hähnle wrote: On 20.03.2017 14:33, Markus Wick wrote: Am 2017-03-20 14:21, schrieb Nicolai Hähnle: On 17.03.2017 18:59, gregory hainaut wrote: If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. It would be nice if glthread could handle this properly, but I don't currently see how. The dispatcher thread needs a map of all valid buffer objects. So we need to update such a map on all glGenBuffers/glDeleteBuffers calls. So the overhead will be the map lookup on all affected glBindBuffer calls. You're right. Ridiculous details of the OpenGL spec make this interesting, actually, because Section 6.1 (Creating and Binding Buffer Objects) of the OpenGL 4.5 (Compability Profile) spec says: "A buffer object is created by binding an unused name to a buffer target. The binding is effected by calling void BindBuffer( enum target, uint buffer ); target must be one of the targets listed in table 6.1. If the buffer object named buffer has not been previously bound, or has been deleted since the last binding, the GL creates a new state vector, initialized with a zero-sized memory buffer and comprising all the state and with the same initial values listed in table 6.2." But this language is different from that for core profiles, where a call to glGenBuffers is required. So in this case, the compatibility profile spec is actually better for performance :/ Cheers, Nicolai Hello, Actually I found another issue on this patch. A deleted buffer is unbound from the context. So validity must be updated accordingly. However I have a tricky question, I think that it is possible to share buffers between multiple contexts. Do we want to support it with glthread ? If yes, it will require either Ouch, yeah. It's getting complicated. * to duplicate the reference counting logic Do we really need to duplicate the logic? Perhaps the shadow copy of bindings in the application thread can have pointers to the buffer objects as well? Then it's the same reference counting logic, and some code can be shared between the application and GL threads. This requires creating buffer objects in the application thread, and changing the marshalling of GenBuffers and CreateBuffers to pass those pointers, but I think it's doable. I think that Gen/CreateBuffers could even be asynchronous, though I think that's dependent on all buffer ops doing the buffer name lookups in the application thread -- otherwise you get buffer objects "traveling back in time", and code like this might execute successfully: glNamedBufferStorage(N, ...); /* N does not exist yet */ glCreateBuffers(1, &bufobj); /* Allocates buffer name N as buffer */ Maybe it all boils down to this: If buffer name handling is spread across the application thread and the GL thread, things get tricky and there are corner cases to watch out for. So one option is to move all buffer name handling into the application thread. This means that all API functions that take a buffer name as parameter need special marshaling that looks up the buffer object in the application thread and marshals the buffer object pointer instead of the buffer name. There's an awful lot of those functions with DSA, but at least it should still be possible to autogen the marshaling. For API functions that take a buffer target, we'd have a choice of having them work as before, or adjusting them in the same way. Adjusting them in the same way would put more load on the application thread without a clear advantage, so best to leave them as-is. I like that it's a conceptually clean approach, but it's an awfully big change. * Or to use a synchronous delete and peep into the context to check if the buffer is still alive As long as the shadow copy of bindings is in terms of buffer names, you need to watch out for the ABA-style problem that you get with asynchronous delete: 1. Context A has a binding of buffer object currently named N. 2. Context B deletes buffer object N. 3. Context A create buffer object, ends up re-using buffer name N. 4. Context A deletes buffer object, re-uses buffer name N. At step 4, the application thread will scan the shadow bindings for context A, see the binding of buffer name N, and unbind it. But that's incorrect, because the automatic unbinding is based on the buffer object, not the buffer name. I guess this could be fixed by a separate reference count for the buffer names, but I haven't thought that through fully. Hmm. I think synchronous create + delete, with a shadow copy of bindings that stores pointers instead of buffer names could work and be relatively lightweight. Cheers, Ni
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
On Mon, 27 Mar 2017 16:10:32 +0200 Gregory Hainaut wrote: > Hello, > > Sorry I was in vacation. I will update my patch with a hash map to > trace buffer creation/destruction. > > Cheers, > Gregory > > On 3/20/17, Nicolai Hähnle wrote: > > On 20.03.2017 14:33, Markus Wick wrote: > >> Am 2017-03-20 14:21, schrieb Nicolai Hähnle: > >>> On 17.03.2017 18:59, gregory hainaut wrote: > If the application is badly/strangely coded, glthread will make it > worst. > The solution ought to be either fix the app or don't use glthread. > >>> > >>> It would be nice if glthread could handle this properly, but I don't > >>> currently see how. > >> > >> The dispatcher thread needs a map of all valid buffer objects. So we > >> need to update such a map on all glGenBuffers/glDeleteBuffers calls. So > >> the overhead will be the map lookup on all affected glBindBuffer calls. > > > > You're right. Ridiculous details of the OpenGL spec make this > > interesting, actually, because Section 6.1 (Creating and Binding Buffer > > Objects) of the OpenGL 4.5 (Compability Profile) spec says: > > > > "A buffer object is created by binding an unused name to a buffer > > target. The binding is effected by calling > > > > void BindBuffer( enum target, uint buffer ); > > > > target must be one of the targets listed in table 6.1. If the buffer > > object named buffer has not been previously bound, or has been deleted > > since the last binding, the GL creates a new state vector, initialized > > with a zero-sized memory buffer and comprising all the state and with > > the same initial values listed in table 6.2." > > > > But this language is different from that for core profiles, where a call > > to glGenBuffers is required. So in this case, the compatibility profile > > spec is actually better for performance :/ > > > > Cheers, > > Nicolai > > Hello, Actually I found another issue on this patch. A deleted buffer is unbound from the context. So validity must be updated accordingly. However I have a tricky question, I think that it is possible to share buffers between multiple contexts. Do we want to support it with glthread ? If yes, it will require either * to duplicate the reference counting logic * Or to use a synchronous delete and peep into the context to check if the buffer is still alive * Or any better idea ^^ Cheers, Gregory ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
Hello, Sorry I was in vacation. I will update my patch with a hash map to trace buffer creation/destruction. Cheers, Gregory On 3/20/17, Nicolai Hähnle wrote: > On 20.03.2017 14:33, Markus Wick wrote: >> Am 2017-03-20 14:21, schrieb Nicolai Hähnle: >>> On 17.03.2017 18:59, gregory hainaut wrote: If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. >>> >>> It would be nice if glthread could handle this properly, but I don't >>> currently see how. >> >> The dispatcher thread needs a map of all valid buffer objects. So we >> need to update such a map on all glGenBuffers/glDeleteBuffers calls. So >> the overhead will be the map lookup on all affected glBindBuffer calls. > > You're right. Ridiculous details of the OpenGL spec make this > interesting, actually, because Section 6.1 (Creating and Binding Buffer > Objects) of the OpenGL 4.5 (Compability Profile) spec says: > > "A buffer object is created by binding an unused name to a buffer > target. The binding is effected by calling > > void BindBuffer( enum target, uint buffer ); > > target must be one of the targets listed in table 6.1. If the buffer > object named buffer has not been previously bound, or has been deleted > since the last binding, the GL creates a new state vector, initialized > with a zero-sized memory buffer and comprising all the state and with > the same initial values listed in table 6.2." > > But this language is different from that for core profiles, where a call > to glGenBuffers is required. So in this case, the compatibility profile > spec is actually better for performance :/ > > Cheers, > Nicolai > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
Am 2017-03-20 14:21, schrieb Nicolai Hähnle: On 17.03.2017 18:59, gregory hainaut wrote: If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. It would be nice if glthread could handle this properly, but I don't currently see how. The dispatcher thread needs a map of all valid buffer objects. So we need to update such a map on all glGenBuffers/glDeleteBuffers calls. So the overhead will be the map lookup on all affected glBindBuffer calls. Regards, degasus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
On 20.03.2017 14:33, Markus Wick wrote: Am 2017-03-20 14:21, schrieb Nicolai Hähnle: On 17.03.2017 18:59, gregory hainaut wrote: If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. It would be nice if glthread could handle this properly, but I don't currently see how. The dispatcher thread needs a map of all valid buffer objects. So we need to update such a map on all glGenBuffers/glDeleteBuffers calls. So the overhead will be the map lookup on all affected glBindBuffer calls. You're right. Ridiculous details of the OpenGL spec make this interesting, actually, because Section 6.1 (Creating and Binding Buffer Objects) of the OpenGL 4.5 (Compability Profile) spec says: "A buffer object is created by binding an unused name to a buffer target. The binding is effected by calling void BindBuffer( enum target, uint buffer ); target must be one of the targets listed in table 6.1. If the buffer object named buffer has not been previously bound, or has been deleted since the last binding, the GL creates a new state vector, initialized with a zero-sized memory buffer and comprising all the state and with the same initial values listed in table 6.2." But this language is different from that for core profiles, where a call to glGenBuffers is required. So in this case, the compatibility profile spec is actually better for performance :/ Cheers, Nicolai ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
On 17.03.2017 18:59, gregory hainaut wrote: On Fri, 17 Mar 2017 13:11:31 +0100 Markus Wick wrote: Hi gregory, Am 2017-03-17 10:25, schrieb Gregory Hainaut: diff --git a/src/mesa/main/marshal.c b/src/mesa/main/marshal.c index f8cad30..43a70d4 100644 --- a/src/mesa/main/marshal.c +++ b/src/mesa/main/marshal.c @@ -214,6 +218,12 @@ track_vbo_binding(struct gl_context *ctx, GLenum target, GLuint buffer) */ glthread->element_array_is_vbo = (buffer != 0); break; + case GL_PIXEL_UNPACK_BUFFER: + glthread->pixel_unpack_buffer_bound = (buffer != 0); + break; + case GL_PIXEL_PACK_BUFFER: + glthread->pixel_pack_buffer_bound = (buffer != 0); + break; } } I wonder what shall happen if buffer is not 0, but neither a valid buffer object. So the glBindBuffer call will fail, and there would still be no buffer bound. The comment above this function explains it very well. degasus Hello degasus, What shall happen ? => Honestly I don't know. Is the behavior 100% defined when you hit a gl error ? Yes, the behavior is 100% defined: GL commands that set an error must leave the internal state of the GL unmodified (except when the error is GL_OUT_OF_MEMORY, then all bets are off). What will happen ? => It depends on the gl transfer operation that will follow the bind. Let's take some examples glBindBuffer(invalid_buffer); // if no buffer is bound, offset_to_pbo will be interpreted as a memory // pointer. Crash is expected (even with gl thread off) glTextureSubImage1D(., offset_to_pbo); // Now, if the application know that buffer isn't bound (hazardous dev or // using an is/get API to check the status). The application will use // a real memory pointer. It will be fine without glthread. But it will // crash with (the current) glthread. glTextureSubImage1D(., memory_ptr); If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. It would be nice if glthread could handle this properly, but I don't currently see how. Cheers, Nicolai Best regards, Gregory ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
Tested-by: Dieter Nützel Am 17.03.2017 10:25, schrieb Gregory Hainaut: Improve speed on PCSX2 v2: Add ppbo/ubpo status in XML file Disable variable parameter (as the pointer would be a fixed offset) Signed-off-by: Gregory Hainaut --- src/mapi/glapi/gen/ARB_direct_state_access.xml | 16 +++ src/mapi/glapi/gen/ARB_robustness.xml | 2 +- src/mapi/glapi/gen/gl_API.dtd | 10 + src/mapi/glapi/gen/gl_API.xml | 28 +- src/mapi/glapi/gen/gl_marshal.py | 25 ++- src/mapi/glapi/gen/marshal_XML.py | 19 - src/mesa/main/glthread.h | 10 + src/mesa/main/marshal.c| 16 --- 8 files changed, 90 insertions(+), 36 deletions(-) diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml b/src/mapi/glapi/gen/ARB_direct_state_access.xml index 43841bb..8d98c2b 100644 --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml @@ -374,7 +374,7 @@ - + @@ -384,7 +384,7 @@ - + @@ -396,7 +396,7 @@ - + @@ -410,7 +410,7 @@ - + @@ -420,7 +420,7 @@ - + @@ -432,7 +432,7 @@ - + @@ -523,7 +523,7 @@ - + @@ -532,7 +532,7 @@ - + diff --git a/src/mapi/glapi/gen/ARB_robustness.xml b/src/mapi/glapi/gen/ARB_robustness.xml index 9b2f2f0..6e1ac09 100644 --- a/src/mapi/glapi/gen/ARB_robustness.xml +++ b/src/mapi/glapi/gen/ARB_robustness.xml @@ -82,7 +82,7 @@ - + diff --git a/src/mapi/glapi/gen/gl_API.dtd b/src/mapi/glapi/gen/gl_API.dtd index b464250..447b03a 100644 --- a/src/mapi/glapi/gen/gl_API.dtd +++ b/src/mapi/glapi/gen/gl_API.dtd @@ -122,14 +122,16 @@ param: offset data should be padded to the next even number of dimensions. For example, this will insert an empty "height" field after the "width" field in the protocol for TexImage1D. - marshal - One of "sync", "async", "draw", or "custom", defaulting to -async unless one of the arguments is something we know we can't -codegen for. If "sync", we finish any queued glthread work and call + marshal - One of "sync", "async", "draw", "ppbo", "upbo" or "custom", +defaulting to async unless one of the arguments is something we know we +can't codegen for. If "sync", we finish any queued glthread work and call the Mesa implementation directly. If "async", we queue the function call to be performed by glthread. If "custom", the prototype will be generated but a custom implementation will be present in marshal.c. If "draw", it will follow the "async" rules except that "indices" are -ignored (since they may come from a VBO). +ignored (since they may come from a VBO). If "ppbo"/"upbo", it will +follow the "async" rules when a pack/unpack pixel buffer is bound +otherwise it will follow the "sync" rules. marshal_fail - an expression that, if it evaluates true, causes glthread to switch back to the Mesa implementation and call it directly. Used to disable glthread for GL compatibility interactions that we don't diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 15d7e4f..561f2b5 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -2149,7 +2149,7 @@ - + @@ -2161,7 +2161,7 @@ - + @@ -2640,7 +2640,7 @@ - + @@ -3293,7 +3293,7 @@ - + @@ -3305,7 +3305,7 @@ - + @@ -4005,7 +4005,7 @@ - + @@ -4019,7 +4019,7 @@ - + @@ -4501,7 +4501,7 @@ - + @@ -4514,7 +4514,7 @@ -marshal="sync"> +marshal="upbo"> @@ -4526,7 +4526,7 @@ - + @@ -4537,7 +4537,7 @@ - + @@ -4552,7 +4552,7 @@ - + @@ -4565,7 +4565,7 @@ - + @@ -4576,7 +4576,7 @@ - + diff --git a/src/mapi/glapi/gen/
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
Hi gregory, Am 2017-03-17 10:25, schrieb Gregory Hainaut: diff --git a/src/mesa/main/marshal.c b/src/mesa/main/marshal.c index f8cad30..43a70d4 100644 --- a/src/mesa/main/marshal.c +++ b/src/mesa/main/marshal.c @@ -214,6 +218,12 @@ track_vbo_binding(struct gl_context *ctx, GLenum target, GLuint buffer) */ glthread->element_array_is_vbo = (buffer != 0); break; + case GL_PIXEL_UNPACK_BUFFER: + glthread->pixel_unpack_buffer_bound = (buffer != 0); + break; + case GL_PIXEL_PACK_BUFFER: + glthread->pixel_pack_buffer_bound = (buffer != 0); + break; } } I wonder what shall happen if buffer is not 0, but neither a valid buffer object. So the glBindBuffer call will fail, and there would still be no buffer bound. The comment above this function explains it very well. degasus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
On Fri, 17 Mar 2017 13:11:31 +0100 Markus Wick wrote: > Hi gregory, > > Am 2017-03-17 10:25, schrieb Gregory Hainaut: > > diff --git a/src/mesa/main/marshal.c b/src/mesa/main/marshal.c > > index f8cad30..43a70d4 100644 > > --- a/src/mesa/main/marshal.c > > +++ b/src/mesa/main/marshal.c > > @@ -214,6 +218,12 @@ track_vbo_binding(struct gl_context *ctx, GLenum > > target, GLuint buffer) > > */ > >glthread->element_array_is_vbo = (buffer != 0); > >break; > > + case GL_PIXEL_UNPACK_BUFFER: > > + glthread->pixel_unpack_buffer_bound = (buffer != 0); > > + break; > > + case GL_PIXEL_PACK_BUFFER: > > + glthread->pixel_pack_buffer_bound = (buffer != 0); > > + break; > > } > > } > > > > I wonder what shall happen if buffer is not 0, but neither a valid > buffer object. So the glBindBuffer call will fail, and there would still > be no buffer bound. > The comment above this function explains it very well. > > degasus Hello degasus, What shall happen ? => Honestly I don't know. Is the behavior 100% defined when you hit a gl error ? What will happen ? => It depends on the gl transfer operation that will follow the bind. Let's take some examples glBindBuffer(invalid_buffer); // if no buffer is bound, offset_to_pbo will be interpreted as a memory // pointer. Crash is expected (even with gl thread off) glTextureSubImage1D(., offset_to_pbo); // Now, if the application know that buffer isn't bound (hazardous dev or // using an is/get API to check the status). The application will use // a real memory pointer. It will be fine without glthread. But it will // crash with (the current) glthread. glTextureSubImage1D(., memory_ptr); If the application is badly/strangely coded, glthread will make it worst. The solution ought to be either fix the app or don't use glthread. Best regards, Gregory ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound
Improve speed on PCSX2 v2: Add ppbo/ubpo status in XML file Disable variable parameter (as the pointer would be a fixed offset) Signed-off-by: Gregory Hainaut --- src/mapi/glapi/gen/ARB_direct_state_access.xml | 16 +++ src/mapi/glapi/gen/ARB_robustness.xml | 2 +- src/mapi/glapi/gen/gl_API.dtd | 10 + src/mapi/glapi/gen/gl_API.xml | 28 +- src/mapi/glapi/gen/gl_marshal.py | 25 ++- src/mapi/glapi/gen/marshal_XML.py | 19 - src/mesa/main/glthread.h | 10 + src/mesa/main/marshal.c| 16 --- 8 files changed, 90 insertions(+), 36 deletions(-) diff --git a/src/mapi/glapi/gen/ARB_direct_state_access.xml b/src/mapi/glapi/gen/ARB_direct_state_access.xml index 43841bb..8d98c2b 100644 --- a/src/mapi/glapi/gen/ARB_direct_state_access.xml +++ b/src/mapi/glapi/gen/ARB_direct_state_access.xml @@ -374,7 +374,7 @@ - + @@ -384,7 +384,7 @@ - + @@ -396,7 +396,7 @@ - + @@ -410,7 +410,7 @@ - + @@ -420,7 +420,7 @@ - + @@ -432,7 +432,7 @@ - + @@ -523,7 +523,7 @@ - + @@ -532,7 +532,7 @@ - + diff --git a/src/mapi/glapi/gen/ARB_robustness.xml b/src/mapi/glapi/gen/ARB_robustness.xml index 9b2f2f0..6e1ac09 100644 --- a/src/mapi/glapi/gen/ARB_robustness.xml +++ b/src/mapi/glapi/gen/ARB_robustness.xml @@ -82,7 +82,7 @@ - + diff --git a/src/mapi/glapi/gen/gl_API.dtd b/src/mapi/glapi/gen/gl_API.dtd index b464250..447b03a 100644 --- a/src/mapi/glapi/gen/gl_API.dtd +++ b/src/mapi/glapi/gen/gl_API.dtd @@ -122,14 +122,16 @@ param: offset data should be padded to the next even number of dimensions. For example, this will insert an empty "height" field after the "width" field in the protocol for TexImage1D. - marshal - One of "sync", "async", "draw", or "custom", defaulting to -async unless one of the arguments is something we know we can't -codegen for. If "sync", we finish any queued glthread work and call + marshal - One of "sync", "async", "draw", "ppbo", "upbo" or "custom", +defaulting to async unless one of the arguments is something we know we +can't codegen for. If "sync", we finish any queued glthread work and call the Mesa implementation directly. If "async", we queue the function call to be performed by glthread. If "custom", the prototype will be generated but a custom implementation will be present in marshal.c. If "draw", it will follow the "async" rules except that "indices" are -ignored (since they may come from a VBO). +ignored (since they may come from a VBO). If "ppbo"/"upbo", it will +follow the "async" rules when a pack/unpack pixel buffer is bound +otherwise it will follow the "sync" rules. marshal_fail - an expression that, if it evaluates true, causes glthread to switch back to the Mesa implementation and call it directly. Used to disable glthread for GL compatibility interactions that we don't diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml index 15d7e4f..561f2b5 100644 --- a/src/mapi/glapi/gen/gl_API.xml +++ b/src/mapi/glapi/gen/gl_API.xml @@ -2149,7 +2149,7 @@ - + @@ -2161,7 +2161,7 @@ - + @@ -2640,7 +2640,7 @@ - + @@ -3293,7 +3293,7 @@ - + @@ -3305,7 +3305,7 @@ - + @@ -4005,7 +4005,7 @@ - + @@ -4019,7 +4019,7 @@ - + @@ -4501,7 +4501,7 @@ - + @@ -4514,7 +4514,7 @@ - + @@ -4526,7 +4526,7 @@ - + @@ -4537,7 +4537,7 @@ - + @@ -4552,7 +4552,7 @@ - + @@ -4565,7 +4565,7 @@ - + @@ -4576,7 +4576,7 @@ - + diff --git a/src/mapi/glapi/gen/gl_marshal.py b/src/mapi/glapi/gen/gl_marshal.py index c89d397..5a9a4f2 100644 --- a/src/mapi/glapi/gen/gl_