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

[Carsten Haitzler (The Rasterman)]

On Sat, 15 Jul 2006 01:17:48 +0100 Felix Bellaby <felix at bellaby.plus.com>
babbled:

> On Fri, 2006-07-14 at 23:46 +0900, Carsten Haitzler wrote: 
> > in my experience of using gl as a 2d api and treating it with painters
> > algorithm... it works just fine speed-wise and can manage all of this
> > easily - without blinking, on any vaguely modern hardware. most of what we
> > need is compositing and transforms - both of which are relatively cheap and
> > fast even brute-force on a modern gpu.
> 
> Okay, I am being too hard on the capacity of current GPUs to composite
> 2D apps using textures. Glitz can already draw into the pixmaps quick
> enough to fulfill users current expectations and texture mapping is
> sufficiently fast to produce acceptable frame rates from the 2D output. 

indeed they can. modern cards capacity via the 3d pipe to do the 2d ops is
quite enough for even my voracious appetite for bling bling :) the problem is
the 2d pipe and it losing 50% of video ram for pixmaps to gl - when most of the
day not a single gl app/call is run.

> My real worry with this environment is its impact on GL apps. Users are
> naturally going to want 3D apps to go with their 3D desktops. Are we
> going to be able to accomodate these at acceptable frame rates into a
> desktop that is being drawn into masses of large framebuffers before
> being distorted onto the screen?

agreed - ttat is then a matter of algorithms for video memory management -
having them there so they are flexible and can shuffle pixmaps between multiple
memory regions (or textures) and use them when they are in (for example) system
ram (have to copy to agp or video ram before using or use software fallbacks
to work on them), agp space (can be used directly but with performance
penalties) and video ram - but the fact is that right now that isnt done well
with half your video ram pre-alloced for textures instead of it being fluid.

generally speaking most gl use tends to be "1 app doing 3d" (a game -
fullscreen or a 3d modeller etc. etc). the fullscreen game & perfromance is
easy to make work well- the pixmaps get kicked out of video ram. in fact a
wm/compositor when it realises 1 app is fullscreen can then release pixmaps for
windows to free up resources voluntarily for that fullscreen application
(with the expense of redrawing the pixmaps if that app un-fullscreens).

> Users may even start to notice that their familiar pseudo-3D widget sets
> do not behave like 3D objects on their 3D desktop. Aaron Platter's
> visually impressive version of glxgears, which maps the normal anim onto
> the faces of a translucent cube, loses part of its gloss when you notice
> that the orientation of the gears is all wrong on the reverse faces.

the problem is - you are talking about something far outside the scope and work
on opengl, dir, memory management, xcomposite, xrender etc. - you are talking
about full 3d windowing systems like croquet - and that is an entirely
different discussion and imho out of scope for this thread. :)

> Perhaps users will take years to become this demanding, and we can
> afford a long grace period using an inefficient hotchpotch of 2D and 3D
> drawing methods. Perhaps not.
> 
> Felix
> 
> 


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