Re: Xvideo acceleration: GATOS for PPC?
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 mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
Reply to: