AIGLX on Radeon Mobility

Owen Taylor otaylor at redhat.com
Thu Feb 23 11:44:26 PST 2006


On Thu, 2006-02-23 at 21:12 +0200, Daniel Stone wrote:
> On Thu, Feb 23, 2006 at 01:31:31PM -0500, Owen Taylor wrote:
> > On Thu, 2006-02-23 at 10:57 -0500, Adam Jackson wrote:
> > > On Thursday 23 February 2006 06:08, Ross Burton wrote:
> > > Not possible; the aiglx branch in its current form will never dispatch into 
> > > libGLcore.
> > > 
> > > I suspect if you were to run sysprof or similar you'd find all your time being 
> > > spent in pushing texture images to the card.  Right now the aiglx branch is 
> > > pretty much limited to the bus write bandwidth, which is lame.  What we 
> > > really need is the ability to texture directly from offscreen-but-on-card 
> > > pixmaps, rather than what we do right now which is render them in host memory 
> > > and then blast across.
> > > 
> > > I'll try to hack up something to do that in the next few days if I get a spare 
> > > moment.
> > 
> > But updating textures should be irrelevant when dragging windows around,
> > right?
> > 
> > Could damage bugs be causing excessive texture updates? luminocity
> > needed some hacks to the X server to work around excessive exposes being
> > generated by DAMAGE.
> 
> IIRC, that patch was to only damage visible regions, right?  In that
> case, it's completely bogus in the compmgr case, being that you can no
> longer make any judgements on visibility or not.

No, not at all. What the hack did was suppress generating of damage
events *for a window* when that window was moved relative to its parent.

Clearly, there is no damage to the window in that case. 

The hack patch we were using for luminocity broke the default
compositor... I think that was just because the default compositing code
was relying on the excessive damage events in this case and didn't
properly redraw the parent when children were moved.

Regards,
					Owen





More information about the xorg mailing list