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

[Carsten Haitzler (The Rasterman)]

On Thu, 13 Jul 2006 15:54:07 +0100 Felix Bellaby <felix at bellaby.plus.com>
babbled:

> On Thu, 2006-07-13 at 22:24 +0900, Carsten Haitzler wrote:
> > > Xcomposite frees its pixmaps when windows are unmapped, and composite
> > > managers should release any other storage at the same time. I presume
> > > that XComposite only creates a new pixmap when the window is remapped,
> > > since it would be completely pointless creating one until then. 
> > 
> > but if you want "expose" "live icons" (icon updates while app is minimized)
> > you need to keep the pixmap around - that is what i am talking about :)
> >
> > ...
> >
> > depends on what you are doing - what if i have a pager that displays a
> > perfect miniature of each virtual desktop - LIVE with windows updating in
> > each? perfectly feasible with xcomposite these days, and users actually have
> > expressed a desire in it and it has a use (you can see the apps on other
> > desktops finish their work or update and then you know if you should go
> > have a look at them or not). this case would eat up an absolute boatload of
> > video ram. and trust me - that is not far down the road :)
> 
> Well, they must have good eyesight. :) 

ok - if your content is TEXT it will be hard to read - but lets say its a slow
website - and it is loading. you can watch it load in a corner of your screen
while you go do something more useful. invariably an app will give some hint as
to its state without needing to see all the details. even text filled xterms -
if you have a compile going and its scrolling along. once it STOPS scrolling
you know the compile is done (if the compile is on a remote box over ssh you
wont be using your local cpu load meter to tell either). anyway - my point is -
people ask for and have uses for such technology and xcomposite makes it all
(finally) possible. you will want to accelerate drawing as the apps wont stop
rendering - they will draw like they do when fully visible. if you use software
fallbacks or pixmap thrash with them - then your xserver will just consume most
of your cpu with these other windows.... not a good thing. my point is that you
still want to reduce unneeded pixmap usage where and when you can.

> Compositing using pixel perfect framebuffers for each application just
> to shrink them to nothing would indeed be extremely expensive, but
> speeding up the drawing into those framebuffers would be a rather feeble
> gesture towards efficiency. Pixel operations can not be performed
> remotely efficiently at entirely the wrong scale. You would be much
> better off switching to a scalable drawing API like cairo for _this_
> kind of work. 

not going to happen - you plan on making every app rescale its own output. also
just because cairo can draw vectors - doesn't mean it trivially makes such a
thing work out of the box everywhere just by its use. problem is you  can't
just switch all the apps - they come as they come with their various toolkits
or even DIY drawing. a scalable drawing kit doesnt suddenly make blit
operations work properly when scaled down or for that matter most operations.
it isn't so simple. the only sane solution is to let the app draw to its full
sized window as a pixmap ans post-scale to the icon version.

> > > However, the issue that we were addressing here was whether all the
> > > expensive buffering involved in compositing might provide a means of
> > > avoiding doing the cheaper buffering done without compositing. Doing
> > > things twice over is never more efficient than doing them once.
> > 
> > indeed - that was the original topic - unfortunately there is a hole with it
> > that still requires invisible copies of the data before the compositor sees
> > it to avoid nasty artifacts during updates. :(
> 
> The copies of the data can either occur before the compositor sees them,
> as they have been implemented in gtk, or they can occur within the
> compositor, as extraneous factors have been forced me to implement them.
> Given my poor understanding of the mystical processes that occur within
> nvidia and ATI, I remain somewhat agnostic concerning the relative
> merits of these two possibilites. 

either way - you need a copy. it is better for the app to do it then 1. it
works without a compositor and does "artifact free" redraws, and it makes life
for the compositor a bit easier.

> Your approach reduces the total memory that needs to be allocated at any
> specific time by allowing the toolkit to choose when to buffer and which
> areas to buffer. However, nvidia seem to be confessing that this memory
> will currently be alloced and dealloced in RAM and the drawing
> operations will make little use of the GPU. 

that is a matter of a bad driver implementation - but i seriously do not
believe this. i can allocate a pixmap xcopyarea from it to other pixmaps at
blinding speeds - it's in video ram and it's using the gfx chipset to do the
blits. it's not done by cpu. the problem is the opengl <-> 2d world mix. in the
past opengl and 3d have been done so entirely separately and differently that
it si when you cross the boundaries of these 2 worlds and want to mix and match
them - you run into the slowest operations and biggest inefficiencies. that is
a matter of fixing drivers to no longer see both as distinctly different worlds.

> My approach maximises the total memory that needs to be allocated by
> using a texture to buffer the entire window pixmap. However, when the
> GPU is being underutilised, then this memory should be located in VRAM
> and the drawing operations may make better use of the GPU.
> 
> This suggests that high end GPUs might be able to benefit from
> compositor based buffering, just as low end GPUs have benefitted from
> gtk buffering for many years. However, I will need to see a lot more
> evidence of high end GPUs compositing at high speeds before I take this
> side of the argument as seriously as the other.
> 
> Felix
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)