[Mesa3d-dev] Re: GLX and Xgl

[Owen Taylor]

On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote:
> David Reveman wrote:
> 
> > The problem is that with Composite extension present a drawable can at
> > any time be redirected to a pixmap. So what do we do if the native GL
> > stack can't handle this? With framebuffer objects available we can
> > probably always allocate another texture and redirect drawing to it, the
> > native GL stack will handle software fall-back if necessary. What do we
> > do when framebuffer objects are not available?
> 
> When an XVisualInfo is used to create the context (i.e., using 
> glXCreateContext) and the pixmap (i.e., using glXCreateGLXPixmap), the 
> context *MUST* support rendering to a pixmap.  When using the fbconfig 
> interfaces, there is a bit in the fbconfig that specifies whether or not 
> the fbconfig can be used with a pixmap.
> 
> So, if you make the following call:
> 
> const int attribs[] = { GLX_DRAWABLE_TYPE,
>                            GLX_WINDOW_BIT | GLX_PIXMAP_BIT,
>                          None };
> 
> ...
> 
> configs = glXChooseFBConfig( dpy, screen, attribs, & num_configs );
> 
> The fbconfigs you get back, if any, will all support creating contexts 
> that can render to both windows and pixmaps.
> 
> I think it is perfectly reasonable for us to require that, in addition 
> to the other requirements for available fbocnfigs, any implementation 
> support at least one fbconfig that meets those requirements.  This is 
> especially true since rendering to pixmaps already has to be supported 
> for the pre-1.3 GLX interfaces.
> 
> You can be 90+% sure that nobody will hardware accelerate rendering to 
> pixmaps.  Of course, that doesn't seem to be a problem for you anyway. ;)

I get the impression that you are looking at the wrong side of rendering
to pixmaps ... the ability to render to a pixmap via the GL API is 
really pretty uninteresting. The *implementation* of such is what
we need.

Hardware acceleration to "pixmaps" is exactly what we need
here, because a redirected window is (from the point of view of the
server internals) a pixmap, and in fact can be named as a pixmap via
the Composite API.

For indirect rendering, we can simply redefine a "pixmap" to be a fbo,
but for direct rendering, we need something that: 

 A) Has a global XID
 A) Can be rendered to by multiple clients
 B) Is offscreen

Which is pretty much the general problem of accelerated rendering to 
a pixmap. We don't have to support rendering to *all* pixmaps, but we
don't escape what seems to me to be the hard parts of rendering to
pixmaps.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050412/c04f1fc3/attachment.pgp>