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

Felix Bellaby felix at
Thu Jul 13 06:40:27 PDT 2006

On Thu, 2006-07-13 at 13:44 +0200, Clemens Eisserer wrote:
> > Since nVidia are managing to pipeline to these pixmaps, it is likely
> > that the alloc/dealloc process is an illusion. Presumably, they are
> > firing the drawing operations somewhere into a permanently allocated
> > area of video memory and just making it look like new memory to the
> > client side. The GPU has to know where the final rastering is to go
> > somewhere before the end of the pipeline and probably needs the info
> > right at the start.
> Sorry I think  you misunderstood me ;-)
> Nobody pipelines anything , nvidia developers just confirmed that
> allocation/deallication is a really bad thing and that this is the
> reason why so much time is spent inside of malloc and software
> rendering routines.
> They first allocate a pixmap in RAM and only if its "worth" to put it
> into VRAM (first copyarea?) the upload it into vram. However future
> nvidia drivers will allow to disable that feature with the result that
> a lot of time is spent waiting for the GPU.

Sorry to reply to this twice, but I would rather not misundertand you
twice. Do you mean that nvidia never pipeline any drawing to any
pixmaps, or that they only pipeline to pixmaps in VRAM, or that they
only pipeline GL to pixmaps in VRAM or that they only pipeline to
pBuffers ?

I would imagine that pipelining occurs for GL drawing operations onto
pixmaps once they are shuffled into VRAM. However, I could not really
hazard a guess as to how much Xlib drawing is pipelined onto pixmaps,
even when in VRAM. Pipelining would cease to be an issue for Xorg/Xlib
apps under compositing if it were never available. However, it might
still be factor worth considering within Xgl/Xlib apps.


More information about the xorg mailing list