[Xcb] Vendor Requests in GLX

[Jamey Sharp]

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?)

> 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