[Mesa3d-dev] Re: GLX and Xgl

[Owen Taylor]

On Tue, 2005-04-12 at 11:52 -0700, Ian Romanick wrote:
> Owen Taylor wrote:
> > On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote:
> > 
> >>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.
> 
> ...which will quite likely never happen.  There *are* reasons that 
> OpenGL implementors abandoned pixmaps and invented pbuffers.

Let me be clear on what is needed.

 - We don't need to be able to take a random Pixmap ID, and render to 
   it from a direct rendering client.

 - We *do* need to be able to do rendering to an offscreen buffer from
   a direct rendering client, then reference that with a pixmap ID  
   in the server internals 

The only real reason I see the second as being easier than the first
is that we know ahead of time (potentially at least) that the piece
of offscreen memory is going to be used for GL rendering. (*)

> > 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.
> 
> At this point, I'm pretty confused.  There is no hardware accelerated 
> direct-rendering to pixmaps today.  Why will it be missed if it's not 
> implemented?  I think I missed some detail as to why this needs to be 
> exposed.

We don't need hardware accelerated direct rendering to pixmaps. We
do need hardware accelerated direct rendering to pieces of memory
that can be named as pixmaps.

Just to review, the basic architecture of composite is:
                            
 Client -- renders  -->       Window
                      +-----------------+
                           [ backed ]
                      +-----------------+
                             Pixmap        -- composites --> Screen
                                             (compositing manager )

The rendering step could be direct GL, indirect GL, X RENDER, or the
classic X protocol. 

The compositing step could be indirect GL or RENDER.

Currently, we think that indirect GL is the right thing, for that we
actually just need to name the window contents as a texture, and not as
a Pixmap, but the ability to name it as a Pixmap is in Composite
protocol.

Note that one possible simplification is to only support double
buffered rendering to the back buffer and make the SwapBuffers
step copy from fbo to pixmap/texture.

Regards,
						Owen

(*) Even that isn't a big advantage, since we could always just migrate
    the pixmap.

-------------- 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/35f9568a/attachment.pgp>