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

[Carsten Haitzler (The Rasterman)]

On Fri, 14 Jul 2006 23:32:41 -0700 Allen Akin <akin at pobox.com> babbled:

> On Sat, Jul 15, 2006 at 10:46:36AM +0900, Carsten Haitzler wrote:
> | On Sat, 15 Jul 2006 01:17:48 +0100 Felix Bellaby <felix at bellaby.plus.com>
> | babbled:
> | 
> | > Okay, I am being too hard on the capacity of current GPUs to composite
> | > 2D apps using textures. ...
> | 
> |                                                            ... 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.
> 
> The static allocation problem is fixable.  Overcommitting video ram is a
> bigger problem, and compositing systems are naturally more likely to
> suffer from it because they require unbounded amounts of memory.

indeed they will be much more video ram hungry. it'd actually be nice to be
able to query the location of a pixmap (or video vs agp vs system ram
resources) and so possibly do smart things - like just free up excess pixmaps
when resources get low.

> It's ironic that we target rendering semantics (embodied in the Render
> extension) optimized for older and smaller systems without advanced
> GPUs, but in the desktop world we also target a display environment
> (using compositing window management) that's optimized for systems with
> a lot of video memory -- which mostly happen to be the systems with
> advanced GPUs.
> 
> | generally speaking most gl use tends to be "1 app doing 3d" (a game -
> | fullscreen or a 3d modeller etc. etc). ...
> 
> That's true in today's Open Source desktop environments.  It wasn't true
> in the old Iris GL days, for example, so it might not always be true in
> the future.  Or in Vista and recent versions of OS X.

sure - but how many "3d" apps will you have at once - windows with 3d views?
not TOO many. i know where you are coming from - but i don't see things going
to heavily 3d in the X world... any time soon... if ever.

> | > Users may even start to notice that their familiar pseudo-3D widget sets
> | > do not behave like 3D objects on their 3D desktop. ...
> | 
> | the problem is - you are talking about something far outside the scope and
> | work on opengl, dir, memory management, xcomposite, xrender etc. ...
> 
> Today we have multiple subsystems that compete with respect to rendering
> semantics, memory management, etc. so this sort of problem is pretty
> much unavoidable.  There's opportunity for a more integrated approach,
> possibly using a scene-graph for overall rendering control and taking
> advantage of programmability in a low-level API.  Once you know

a scene graph for the whole display - imho is the job of something like croquet
and is out of the scope of what we were discussing :)

> everything that needs to be rendered, with what appearance, and what
> interactions with other objects, you can do a good job of making the
> process efficient and responsive with minimum resources.  (Game engines
> illustrate how to do much of what's needed.)  Without that, it's a
> matter of finding enough clever heuristics to glue the subsystems
> together, and avoiding the combinations that still don't work well.

yup. right now i think our problem is basically memory management of 2d pixel
sets (be it pixmaps or textures) and the problem of copying/transferring
between these 2 (currently) distinct resource sets (texture/pbuffer 3d vs 2d
pixmap) where in reality we really should see it as a single set of 2d pixel
surfaces.

> Allen
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


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