[MPlayer-dev-eng] [PATCH] -vo tdfxfb vs linux-2.6
Robert Henney
robh at rut.org
Fri Jan 4 02:04:57 CET 2008
On Mon, Dec 17, 2007 at 11:07:48PM +0300, Michael Kostylev wrote:
>
> Description of the problem:
> http://lists.mplayerhq.hu/pipermail/mplayer-users/2004-June/046038.html
> Mmap fails because the mmio region is mapped into kernel space only.
> Unfortunately I can't test new code on 2.4 but it seems to work.
appears to work here on a 2.6.18 kernel after applying the patch. didn't
work at all before so definately an improvement in that respect.
don't have a 2.4 machine readily available to test with, sorry.
It likely doesn't have anything to do with your patch, but I made
some observations:
On the test runs I made, using -vo tdfxfb was 2.5 times slower than
using -vo fbdev, which doesn't seem to be right. I know fbdev
requires swscaler to handle the colorspace conversion which tdfxfb can
just offload to the card, but I'm not convinced that it's the card
that's slowing things down. the test videos I used were 640x360
12bpp 23.976 fps; nothing resolution heavy. also the benchmarks I ran
seem to indicate that with tdfxfb less time was spent in the VO (which
is expected) but a lot more time was spent in the VC (which is not
expected, especially as that is when the swscaler is not being used).
fbdev:
BENCHMARKs: VC: 6.988s VO: 2.829s A: 0.000s Sys: 0.082s = 9.898s
BENCHMARK%: VC: 70.5964% VO: 28.5768% A: 0.0000% Sys: 0.8268% = 100.0000%
tdfxfb:
BENCHMARKs: VC: 21.947s VO: 0.867s A: 0.000s Sys: 0.078s = 22.892s
BENCHMARK%: VC: 95.8715% VO: 3.7865% A: 0.0000% Sys: 0.3420% = 100.0000%
also noticed a strange issue with fb depth. at a depth of 32 the
video from fbdev and tdfxfb both looked stunning, but at a depth of 16
the tdfxfb video was very poor while the fbdev still looked just as
good as it did in 32. I have no idea what might cause this other than
maybe the onboard converter does not function well with 16bit depth.
More information about the MPlayer-dev-eng
mailing list