[Xcb] XCB and OpenGL, help and/or project ideas wanted

[Peter Harris]

On Wed, Jun 17, 2009 at 7:53 AM, Riku Salminen wrote:
>
> After a while I realized that XCB-GLX by itself cannot be used to set up
> a rendering context. For that you need the GLX api from your OpenGL
> implementation (from libGL.so). In addition to sending the normal X
> requests, the GLX API functions modify local client state that's hidden
> in libGL.so. The GLX API is closely tied to Xlib and there's no way to
> use it without Xlib.

> The solution would be to have an XCBified replacement for the GLX API,
> but since the GLX API is standardized, this is one of those 80%
> political 20% technical issues.
>
> And now for the questions:
>
> Can anyone verify my findings?

Yes, that's pretty much the size of things. Basically, to get decent
performance from large datasets, you need to use direct rendering.
Which means *not* going through the X connection, which means not
using XCB (or even Xlib) for the majority of your functions.

This is made worse by the fact that indirect (over-the-network) OpenGL
has not been hardware accelerated on Linux until recently, so some of
the proprietary drivers still don't support indirect acceleration.

So you need to use some sort of libGL to handle the direct rendering
parts, and the current API is tied to Xlib.

> What is the general status of XCB/OpenGL at the moment and who is or has
> been working on it?

Most OpenGL work is going on in Mesa.

Mesa has an XML description of most (all?) OpenGL extensions that
isn't too different from the XML format XCB uses.

A pure-XCB (ie. without Mesa) solution wouldn't be very useful, in my
opinion. You'd just be reproducing large chunks of Mesa for no
discernible benefit. For example, the GLX "Render" request is broken
down into sub-requests. There are literally hundreds of possible
sub-requests. Providing a way to encode them all directly within XCB
would be a herculean task. Plus, then you wouldn't be able to use
legacy OpenGL code or libraries (as you currently can with Mesa).

> XCB-only OpenGL does not seem to be possible with proprietary graphics
> driver-provided OpenGL implementations, but what about Mesa? If it's
> possible, how do you set up a Mesa-OpenGL context with XCB? Are there
> any open source graphics drivers that can be used with XCB?

Mesa already has the beginnings of support for XCB. Search for USE_XCB
in the mesa source code. As of right now, it still uses the Xlib
Display, and calls XGetXCBConnection.

> I'm kind of in a hairy situation at the moment, I am participating in a
> campaign called Kesäkoodi (http://www.coss.fi/kesakoodi), which is
> similar to Google's Summer of Code. So I'm getting paid for three months
> to work on XCB. My project is supposed to be XCB/OpenGL, but I guess
> it's not that restricted.
>
> So, now that I'm stuck, I'd like to hear about ideas on how to go on. If
> there's nothing on XCB/OpenGL, another XCB-related project will do.

Adding a pure-xcb interface to Mesa could be an interesting way to
proceed with your project. It would allow OpenGL applications to drop
Xlib entirely (at the cost of losing proprietary driver support, at
least until the proprietary driver makers add the new API to their
libGL).

There are only a few Mesa functions that take an Xlib Display; I
suspect the harder part would be changing the internals to optionally
pass around an xcb_connection_t instead.

To verify that your new interface is viable and functional, you might
consider reworking GLUT (also part of Mesa) to use your new xcb
interface instead of the Xlib one. That looks to be a rather large
project, however.

> X Input methods/internationalized text input could be an intresting
> project to work on, what's the status of that on XCB?

XCB currently lacks helper functions for this. Work in this area would
be appreciated too. (See the xcb/util repository for the current
status. It looks like we have some keysym helpers, but I'm sure you
know that's far from everything needed in this area.)

Peter Harris