[PATCH] glx: swrast can do GLX 1.4 too

Adam Jackson ajax at nwnk.net
Mon Nov 2 08:14:05 PST 2009


On Fri, 2009-10-30 at 11:19 -0400, Kristian Høgsberg wrote:
> On Thu, Oct 29, 2009 at 5:52 PM, Adam Jackson <ajax at nwnk.net> wrote:
> > On Thu, 2009-10-29 at 14:01 -0700, keithp wrote:
> >> Excerpts from Adam Jackson's message of Thu Oct 29 11:01:29 -0700 2009:
> >>
> >> > +    screen->base.GLXmajor = 1;
> >> > +    screen->base.GLXminor = 4;
> >>
> >> Should this define be in a header somewhere?
> >
> > Maybe?  It ends up being variable per renderer atm, so you'd end up with
> >
> > #define GLX_SWRAST_PROTOCOL_MINOR       4
> > #define GLX_DRI_PROTOCOL_MINOR          2
> > #define GLX_DRI2_PROTOCOL_MINOR         4
> >
> > That doesn't seem especially useful, even as documentation.
> >
> > The whole thing is broken, in reality.  pbuffer support and separable
> > read/draw surfaces in the context are features that require some level
> > of hardware (well, renderer) support, and we're not querying the
> > renderer for their presence.
> 
> No, pbuffer support is entirely in GLX and all DRI2 drivers support
> separate draw and read drawables.

I didn't say we weren't giving the right answer, although I did say "in
reality" when I should have said "in theory".  I was trying to say we
were being chummy with the implementation.  Not all DRI1 drivers
necessarily support separate read/draw (although I think they do), and
I'm reasonably sure hardware has existed where the only offscreen
renderbuffer was the backbuffer.  It wouldn't be impossible to implement
pbuffers in that environment, but, the point remains, it requires
renderer support.

Still, swrast _can_ do 1.4, and I don't see a lot of value in
#define'ing that bit of truth.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091102/16fbc241/attachment.pgp 


More information about the xorg-devel mailing list