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

[Allen Akin]

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.

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.

| > 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
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.

Allen