On Sun, 2008-09-28 at 18:46 +0200, Bernie Innocenti wrote: > Tomeu Vizoso wrote: > > > On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese > > <[EMAIL PROTECTED]> wrote: > >> On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: > >>> * build 703, xorg driver = amd, redraws = 200 > >>> - pixbuf: > >>> 98.63s > >>> 96.96s > >>> 96.58s > >>> 97.14s > >>> 99.21s > >>> > >>> * build 703, xorg driver = fbdev, redraws = 200 > >>> - pixbuf: > >>> 55.81s > >>> 55.40s > >>> 55.22s > >>> 55.50s > >>> 55.63s > >>> > >>> * build 2489, xorg driver = amd, redraws = 200 > >>> - pixbuf: > >>> 84.21s > >>> 84.81s > >>> 81.94s > >>> 81.79s > >>> 85.29s > >>> > >>> * build 2489, xorg driver = fbdev, redraws = 200 > >>> - pixbuf: > >>> 62.83s > >>> 62.81s > >>> 62.81s > >>> 62.66s > >>> 63.14s > >>> > >>> - joyride regressed sensibly at rendering with cairo since 703 > >>> - rendering pixbufs is extremely slow on the xo > >>> - server side surfaces are awesome ;) > >>> > >> and btw why is fbdev faster than the geode driver at rendering pixbufs ? > > My performance tests with X 1.3 and 1.4 had shown that turning on EXA > makes many operations slower. It's hard to tell why, but it might have to > do with loosing XShmPut() (MIT shared memory),
EXA does support XShmPutImage(), just not SHM pixmaps. > excessive migration of pixmaps to the framebuffer, and so on. Migration overhead is indeed often the cause of EXA performance issues. Also note that the fbdev driver by default uses a shadow framebuffer in system RAM and only updates the visible screen contents at regular intervals. It might be fairer to compare with Option "ShadowFB" "off", at least assuming the amd driver provides other desirable features the fbdev driver can't provide. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
