On 30 Aug, this message from Michel D�nzer echoed through cyberspace: >> I tried the GATOS drivers on my TiBook (with Josh's fix -- thanks), but they >> give the same performance as the standard one, plus a (probably) endianess >> bug: they seem to 'reverse' successive image blocks on screen; probably 4- >> or 8-pixel-wide blocks... > > Sounds like what I have fixed in the XFree86 r128 driver. :)
Hehe... got your fix from Xfree CVS; it does help indeed ;-) Current GATOS is based on older CVS. >> To sum up my performance comparisons so far, all with XFree 4.1.0 from >> unstable, and vlc 0.2.83: >> >> - Mach64/i386 without GATOS: no Xvideo (driver is broken); vlc uses 45% >> + 16% cpu (two 'consuming' threads); X uses 25% cpu. >> - Mach64/i386 with GATOS driver: Xvideo works, vlc uses 25% (other >> threads insignificant), X uses between 2% and 5% >> - Voodoo3/i386: Xvideo works, X around 25% and vlc around 30% (roughly) >> - Rage128/ppc: Xvideo works, X between 10% and 20%, rest consumed by >> vlc. >> >> The Mach64 is on a Dell laptop w/ Celeron 600, the Voodoo is a PIII/666 >> desktop, and the ppc is my TiBook/400. >> >> So the question is: why does X on the Dell use so little CPU, > > I guess either because it has write combining for the framebuffer or because > top lies. I wouldn't know for top, but I can say that mtrr definitely makes a difference: 45% cpu for X without mtrr, down to roughly 5% with the proper mtrr configured. So that was it. >> and why can't we achieve the same thing on ppc > > We might if we used bus mastering for the video data transfer. There are plans > to implement that, see current discussion on dri-devel. We might be able to squeeze a few percent out of better caching for the framebuffer (making X's framebuffer mapping cacheable enables bursting from the CPU; combined with float or vector stores instead of regular memcpy that should give a boost that _could_ come close to what mtrr achieves on i386. Michel, do you know what X uses to map the framebuffer? I suppose it mmap()s it; but what device? /dev/mem or /dev/fb (which X both has open) or something else? Cheers Michel ------------------------------------------------------------------------- Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes | Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED] | http://www.cpu.lu/~mlan | Learn Always. "
