Need advice: Mobile ATI card with 'shared' memory - EXA performance?

Alan Swanson swanson at ukfsn.org
Thu Dec 8 17:17:31 PST 2005


On Thu, 2005-12-08 at 02:42 +0100, Francesco Biscani wrote:
> On Thursday 08 December 2005 02:05, Dan wrote:

[SNIP]

> The big slowdowns come when you run out of video memory, and you can realize 
> it by monitoring X memory usage with xrestop. When the total size of pixmap 
> buffers approximates your video RAM size you notice great slowdowns, 
> expecially when switching desktops. With my actual setup (64M+1024x768 at 16bit) 
> this seldom happens (I dare to say it never happens). If you go up to 32bit 
> color depth you can trigger the "slow" behaviour much more easily (just open 
> up many windows). In this case I guess going up to 128MB of RAM could help, 
> even if I have not tried yet (and I need to purchase another 512M stick of 
> system ram to go there ;) )
> 
> My (ignorant and based upon only experience) conclusion is that in this 
> specific case the bottleneck is not RAM speed.

The problem here is probably texture thrashing.

I've not looked into how EXA caches textures but if it uses DRI/Mesa when
available, and probably also if it doesn't, then it's using Least Recently
Used (LRU) caching only. LRU is terrible when there are more textures than
memory as it will be continually replacing every single texture every
single frame which is a killer.
[16Mb cache, 18Mb textures; 18Mb bandwidth per frame]

A fallback to Most Recently Used (MRU) caching as in John Carmack's .plan
and on many other sites should be used so that only the last bit of
memory is used as a scratch pad reducing memory bandwidth used.
[16Mb cache, 18Mb textures, 4Mb bandwidth per frame.]

I'd actually been thinking about writing this for Mesa over the Christmas
holidays as it seems a straightforward (for single head) contribution
not being a hardware guru myself.

-- 
Alan.

"One must never be purposelessnessnesslessness."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20051209/4d356f5b/attachment.pgp>


More information about the xorg mailing list