Performance change from X in Fedora Core 4 to Fedora Core 5

[Felix Bellaby]

On Tue, 2006-07-11 at 22:33 -0400, Kristian Høgsberg wrote: 
> > This can be essentially be done within the compositor. The current
> > absence of the texture_from_drawable extension in most environments
> > means that truely portable GL compositors currently have to copy from
> > the Xcomposite Pixmap into a texture using glCopyTexSubimage. This means
> > that the texture acts as a buffer between the Xcomposite Pixmap and the
> > visible screen.
> 
> One assumption that I forgot to mention is that long term we will have
> a unified memory manager that the xserver and the dri drivers use for
> video memory allocation.  With this in place, the X pixmap and the GL
> texture can be the same underlying memory object and
> texture_from_pixmap becomes a zero copy operation that just sets this
> up.
>
> If the compositor only uses glCopyTexSubImage it *has* to copy the
> texture on each damage event,

Copy the _damaged_ part, not the whole texture. 

> , and then each window now has two
> permanent copies in video memory: the compsite backing pixmap and the
> texture.  With a zero-copy texture-from-pixmap we only have an extra
> buffer (e.g. the gtk+ double buffer pixmap) around during repaint and
> it can be allocated to be just big enough to hold the damaged ared.
> When no application is redrawing, only the composite backing pixmaps
> are taking up video memory and the dri drivers can texture directly
> out of these (using texture-from-pixmap) when the composite manager
> recomposites the screen.

DRI is not used in all GLX implementations. Judging by my experience,
the nVidia drivers have problems just sharing a Pixmap handle with a
GLXPixmap handle. The performance implications of synchronising GPU
accesses when texturing from a Pixmap remain a mystery unless you know
what the drivers and GPU are up to behind the scenes. 

The gains to be had from using less GPU memory and avoiding copies of
damaged areas may be less significant that the gains of avoiding the
rapid allocation and deallocation of tiny pixmaps. The GPU will be
unable to use pipelines effectively on drawables that are created and
destroyed rapidly. 

Predicting what will create the best performance based on open source
experience of DRI is not necessarily a good idea. We can only begin to
judge which is the best approach once the (currently non-existant)
accelerated drivers for texture_from_pixmap have matured. 

Felix