Xorg 7.0-rc1 and EXA (radeon 9200)

Carsten Haitzler (The Rasterman) raster at rasterman.com
Fri Oct 28 21:20:41 PDT 2005


On Sat, 29 Oct 2005 12:26:09 +1000 Daniel Kasak <dan at entropy.homelinux.org>
babbled:

> I'm having issues similar to those discussed here.
> 
> My system:
> 
> Apple Powerbook, 1Ghz
> ATI Radeon Mobility 9000 (M9) Lf (AGP)
> Gentoo Linux
> 
> I've got RC1, from a Gentoo ebuild. I've got DRI and EXA enabled. I'm 
> using Enlightenment-0.17. In my script that start enlightenment, I've 
> got the line:
> xcompmgr -Ff &
> 
> After reading Rasterman's receommendation to force cairo to use xrender 
> ( I've got gtk-2.8.6 and cairo-1.0.2 ), I tried to find out how to do 
> this. I couldn't find out, so instead, I made sure I didn't open *any* 
> gtk+ or qt apps. I have *only* done the testing below with apps that use 
> the Enlightenment Foundation Libraries - ie they use evas to render, 
> which is currently using software rendering. Examples of apps I've used:

actually - if you have e17 - you can have it use xrender for everything :)

enlightenment_remote -default-engine-set XRENDER
enlightenment_remote -restart

and e17 will draw everything via xrender - you can go back to software pixel
punching with:

enlightenment_remote -default-engine-set SOFTWARE
enlightenment_remote -restart

it seems to work ok on my dell with an ati radeon 9000 mobility (r250, 64mb
video ram). some off-by-1 errors it seems and display quality takes a fair bit
of a dive due to no filtered downscaling being available with xrender at this
time. i didnt use xcompmgr though. xrender did take a leap in performance in
the last 2 weeks by about 50% - it's actually runing 50% faster than opengl
performance here for the same rendering tasks (damn good job) and that puts it
at about 3 times software rendering speed given my primtiive benchmarks.

> - evidence, in icon mode ( icon mode is rendered by evas )
> - Eterm
> - emblem ( enlightenment background selector )
> - entangle ( enlightenment menu editor )
> 
> The point is that there's no gtk+ stuff.
> 
> At this point, I run transset on a number of windows, drag them around 
> the screen, change desktops, and do 'stuff', and the performance is 
> nothing short of amazing :) If I run an Eterm with 'top', X maxes out at 
> 10% CPU usage for most dragging operations ( of transparent windows ), 
> and the highest is about 40% with lots of transparent windows. 
> Everything is 100% fluid.
> 
> Unfortunately, things go downhill from there. Opening new windows 
> *seems* to trigger the degradation, but it doesn't happen right away. 
> Still, sooner or later, I'll go to open something, and it will take 30 
> seconds to completely start up - because X is at 90% CPU usage.If I 
> continue, X might calm down a little, but half-decent performance is 
> broken up by long periods of almost complete lockups. Even changing 
> desktops seems to bring about performance degradation.
> 
> If I kill xcompmgr, everything is lightning fast again. When I restart 
> xcompmgr, I start out with somewhere between decent and original 
> performance, but get worse again a lot faster. The best solution seems 
> to be to close the window manager completely, and log in again - this 
> gives the most time at full performance.
> 
> I've done the above tests a number of times. That's about the extent of 
> what I can do ... test and report. Sorry. I'm happy to try out whatever 
> people want to suggest, patches, etc.

it smells either like a pixmap leak in xcompmgr or on the server side (run
xrestop and see if anything stands out and seems to grow in terms of pixmap
usage), or simply you are getting your video ram filling up and now x gets to a
pathological state of swapping pixmaps in and out of video ram all the time.
how much video ram do you have?

here's the rough way things pan out for my laptop system: 64mb video ram.
somehow to get xrender to work properly i have to also keep driand opengl
enabled. this eats up 32mb of video ram (half of whatever you have) instantly
as pre-allocated for dri clients. now since i run 1600x1200 at 32bpp the
framebuffer is just a bit under 8mb alone. 24mb spare video ram left now. now
given that i like a desktop wallpaper - this is another (just under) 8mb of
video ram for the wallpaper pixmap. we have now 16mb of video ram left. that
16mb now has to be used to store pixmaps PER WINDOW whichbasically has space
for about 2 fullscreen windows wort of pixels - so once you have opened 2
screenfulls of windows you have now run out of video ram. remember xcomposite
and pixmaps per windows is VIDEO RAM HUNGRY. it will eat your vram for
breakfast and ask about lunch before it's even done.

there is serious work left to be done to alleviate this. 1. m,ake video ram
dynamicallocated as neede dbetween DRI oepngl clients AND the xserver and
pixmaps - so you dont lose half your video ram to start with for no good
reason. secondly adding in a 3rd level of agp ram rendering (render to agp
memory etc.) - putting pixmaps in agp memory and having fast migration between
it and video ram where appropriate. then theres transfer between non-agp ram
and video ram and agp memory and managign that well. then there is the whole
world of actually good management algorithms. right now this is all a bit of a
mess and needs work and your case is hilighting simply that it does. ifr you
had 256mb video ram - like some people do, you would not hit this case so
quickly :)

anyway - point is - there has been some great work done to speed up xrender on
ati chipsets of late - that's great, but there are still major stumbling blocks
on the road to it all being fully usable in a 100% composited secenario.

> But anyway, I have to congratulate the people who have worked on EXA so 
> far. The performance increase over XAA is incredible. Obviously it's not 
> stable yet, but it's going to be great :)
> 
> Dan
> 
> 
> -- 
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------If you are not the
> CanIt administrator and you think this message is spam, please give the id
> 18319 and magic value 1808d985ced3 to postmaster at entropy.homelinux.org to be
> marked as spam.
> 
> Teach CanIt if this mail (ID 18319) is spam:
> Spam:
> http://entropy.homelinux.org/canit/b.php?c=s&i=18319&m=1808d985ced3 Not
> spam:    http://entropy.homelinux.org/canit/b.php?c=n&i=18319&m=1808d985ced3
> Forget vote:
> http://entropy.homelinux.org/canit/b.php?c=f&i=18319&m=1808d985ced3
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
> 
> _______________________________________________
> 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 (東京 日本)



More information about the xorg mailing list