EXA for radeon experimental patch

[Eric Anholt]

On Wed, 2005-08-31 at 09:52 +0200, Lars Knoll wrote:
> On Tuesday 30 August 2005 12:37, Eric Anholt wrote:
> [snip]
> > As a side note: The lack of render acceleration on my r300 has exposed
> > the fact that the migration heuristics aren't working well in the
> > absence of Render acceleration.  Anyone have a suggestion why that would
> > be?
> 
> One idea is that the Software uses both Composite calls and regular 
> blits/solid fills on the pixmap. I know at least Qt does this. Current 
> versions try to avoid using Render when possible, as it usually is a lot 
> slower. 
> 
> So what you might see is that both commands happen and the pixmap gets 
> migrated back on forth all the time. Also a missing DownloadFromScreen 
> implementation makes moving pixmaps into main memory rather slow. 

Since exapict.c will break Composite down into a core operation when
possible, this could make sense.  However, the migration stuff was
designed with that latency built in to migration to hopefully avoid
this.  The exception would be if the dirty stuff was hooked up, where
you could be uploading, doing a render, then throwing away (rather than
downloading) the framebuffer copy when a fallback happened.

> Another think I saw is that compositing onto the framebuffer is still always 
> slow. It might be a good idea is EXA always used DownloadFromScreen (if it 
> exists) to copy all pixmaps for a composite call into main memory before 
> attempting to use fbComposite. 

We would have to allocate and hook up an area in system memory for the
visible screen then.  And, given that I expect people to use compositing
managers (which will be doing a back-buffer pixmap that could migrate
normally anyway), I'm not too interested in it.

One improvement that could be useful would be to have the migration
weighted differently for different operations, based on approximate
costs of doing the operation either in framebuffer or system memory.  I
bet it wouldn't be too hard to make some much better guesses of where
pixmaps should live.

-- 
Eric Anholt                                     eta at lclark.edu
http://people.freebsd.org/~anholt/              anholt at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050831/66289e17/attachment.pgp>