GLX compatible pixelformats
brian.paul at tungstengraphics.com
Tue Nov 14 06:22:43 PST 2006
Roderick Colenbrander wrote:
> For some time I have been rewriting Wine's Opengl32 layer. Right now I'm
> fixing our pbuffer code and because of that I have a question about GLX
> First a little Wine background. Windows programs use GDI in combination with
> a display driver for rendering. Wine contains a X11 driver for rendering. Due
> to various limitations of Wiine's X11 driver we are limited to a single X
> Visual. This visual is created at 'startup' and is GLX compatible (we try to
> find a RGBA format with double buffering, 8bit alpha, 8bit stencil ).
> For most OpenGL programs this single pixel format isn't a very big limitation
> as on Windows programs aren't guaranteed to get what they want anyway. If
> they ask a 32bit format they can in theory get a 8bit format back, so it is
> normal to verify what you got.
> The problem lies in pbuffers in which case the pixel format requirements are a
> bit more strict. The functions which programmers use are similar to
> glXGetFBConfigs and friends which searches for formats which meet you
> requirements. In general programs expect to get atleast one format back.
> Our issue is that we want to advertise as much 'compatible' pixelformats as
> possible (also for things like multisampling and more). I wrote a small test
> app which created a pixmap/pbuffer and checked for each format if it was
> compatible with the format of the GLX Context (I created a context which met
> the same requirements as I mentioned for Wine)
> I got about a dozen of 'compatible' formats with similar R/G/B/A, depth and
> perhaps other things in common. I tried the same program (both using a
> direct/indirect rendering context) on the radeon dri drivers (rv250) and
> using the fglrx drivers. Further users of different cards tried it too.
> In case of pixmaps it found at most one compatible format and the pbuffers
> test failed (most drivers don't support pbuffers).
> Based on my nvidia tests I expected to find a few compatible formats. Are
> there some heuristics which I can use for finding compatible formats (without
> testing)? What's the best way on how to do this? What's the definition of
> compatible? (the specs are vague)
So you're looking for compatibility between a GLX context and one or
more windows plus one or more pbuffers?
Off-hand, I don't recall that there has to exist any pbuffer formats
that match a given window's pixel format. Though, that would probably
be a rare situation.
The definition of compatibility between a rendering context and a
drawable is a bit vague. Though, with recent developments like
framebuffer objects, the rules are getting relaxed a bit.
In Mesa, the check_compatible() function in src/mesa/main/context.c
shows how we test for compatibility between a context and a drawable.
More information about the xorg