[Xcb] Vendor Requests in GLX

[Jeremy Kolb]

Jamey Sharp wrote:
> On Sun, 2005-05-08 at 17:53 -0400, Jeremy Kolb wrote:
> 
>>I'm going through the extension registry and adding support for vendor 
>>glx extensions.  A lot of them just set up new GLX requests which is 
>>easy to do, but others use VendorPrivate/VendorPrivateWithReply. 
>>Basically you call GLXVendorPrivate with a vendor code, context_tag and 
>>then a list of data.  So the layout looks like this:
>>
>>DeleteProgramsARB
>>      1           CARD8           opcode (X assigned)
>>      1           17              GLX opcode (glXVendorPrivateWithReply)
>>      2           4+n             request length
>>      4           1294            vendor specific opcode
>>      4           GLX_CONTEXT_TAG context tag
>>      4           INT32           n
>>      n*4         LISTofCARD32    programs
> 
> 
> (Did they screw these up the same way they botched the QueryFB stuff, or
> whatever we debugged recently? That 'INT32 n' is entirely redundant with
> the request's length field, is it not?)
> 

Not that I know of.  I don't believe that's redundant because of 
padding.  But I'm not sure.  This is just one request.  If you are 
interested I got this one from 
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_program.txt

> 
>>Mesa sets up a VendorPrivate request and then memcpys everything into a 
>>buffer to send just like they do with normal requests.  So how should I 
>>add these? Make a struct for each and then convert it to a (BYTE *) and 
>>pass it in?
> 
> 
> Yeah, this is something unfortunate in the XCB API. I've thought about
> it a little without coming up with any good solutions. XCB's internals
> benefit a lot (performance-wise, and a fair bit in clarity too) by using
> scatter-gather I/O like writev and readv. It seems like it would be a
> pretty big win to let XCB's callers do the same thing, especially in
> cases like this one.
> 
> Here, XCBGLXVendorPrivate needs a single array to follow the context
> tag, but this particular request needs a 32-bit number followed by the
> 'programs' list. Since it's provided by the caller, we can't just
> allocate a spare 4 bytes on the beginning, so under the current XCB API
> Mesa will have to allocate a (4+4*n) byte array and copy both 'n' and
> 'programs' into it, then pass that to XCB (which may copy the whole
> thing into another buffer). Theoretically the 'programs' list could be
> long, so this is a lame thing to have to do.
> 
> A 'writev'-like API fixes the problem, I think. But I haven't come up
> with any design that isn't a pain for people to use. Bart?
> 
> --Jamey
> 

So should I just wait to hear from you guys on how to do this one?

Jeremy