Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound

2017-03-29 Thread Nicolai Hähnle 

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, ); /* 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

Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound

2017-03-28 Thread gregory hainaut 
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

2017-03-27 Thread Gregory Hainaut 
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

2017-03-20 Thread Markus Wick 

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

2017-03-20 Thread Nicolai Hähnle 

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

2017-03-20 Thread Nicolai Hähnle 

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

2017-03-20 Thread Dieter Nützel 

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 @@
 
 

-
+

Re: [Mesa-dev] [PATCH] mesa glthread: allow asynchronous pixel transfer operation when a buffer is bound

2017-03-17 Thread Markus Wick 

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

2017-03-17 Thread gregory hainaut 
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

2017-03-17 Thread 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 @@
 
 
 
-
+
 
 
 
@@ -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