On Thu, Sep 07, 2006 at 09:09:20PM +0100, Alasdair Campbell wrote:
> On 06/09/06, Marko Mäkelä <[EMAIL PROTECTED]> wrote:
> > Now I only have one wishlist item left for DirectFB on Matrox cards:
> > get rid of that busy-waiting in IDirectFBSurface::Flip() by implementing
> > some ioctl() calls to make it interrupt-driven.
>
> Is that a lot of work?
For someone who knows how interrupts are processed in the Linux kernel,
it should not be that hard. I have programmed interrupt routines in
machine language, but not in C on a sophisticated operating system
like the Linux kernel. I think that Ville Syrjälä might have had a
kernel patch for this, but I am not sure how much work it would be
to get it in the 2.6 kernel.
> With my underclocked barton (running at 1350 MHz) the following
> results were got from 'top'.
> [I just took the value for the vdr process with the highest value,
> don't know if this is misleading].
Oh, you must be using LinuxThreads then. I've used NPTL for the past year
(just unset the environment variable LD_ASSUME_KERNEL if you are using
GNU libc 2.3 or later). NTPL should have smaller overhead than LinuxThreads.
> Unpatched:
> -vo dfb:mgatv = ~40%
> -vo dfb: = ~21% ( a lovely figure!)
>
> Patched:
> -vo dfb:mgatv = ~29% (great patch)
> -vo dfb: = ~29%
The usleep() calls should not affect the -vo dfb: code path. You should
perhaps have watched a recording instead of live stream to get more
repeatable results. Anyway, you seem to be getting 10% savings on
dfb:mgatv, about the same as me.
> With results like that, and with Matrox hardware scaled interlaced
> output working in 'VGA' mode, I could nearly run vdr on my old AMD K6
> 500mhz relic.
You need some margin. I was unable to underclock my system, but I think
you will be dropping frames if the CPU load goes above 60% or 70%.
> > I plan to make some OProfile measurements this weekend. At the very least,
> > I will measure the impact of colour space transformation (i.e., let
> > -vo dfb:mgatv show wrong colours by pretending it uses the native output
> > colour space of ffmpeg).
>
> I remember you saying your cable didn't work with "-vo dfb:" because
> that option didn't generate a composite sync signal - well I don't
> think I made it clear enough that I _did_ see a picture of comparable
> (slightly sharper) quality using "-vo dfb:" & the cable from the
> diagram we both used.
And come to think of it, it might be that the problem is not the
colour space conversion but simply the Flip() call. I seem to remember
that Stefan's test program from June or so gave comparable results
for memcpy() and yv12_to_yuy2_il_mmx2(). The only thing that you could
avoid on -vo dfb: output is the memcpy(), i.e., let ffmpeg uncompress
the data directly to the frame buffer (if it does not do so already).
> Basically, latest DirectFB CVS with softdevice option '-vo dfb:' seems
> to generate a composite signal just like '-vo dfb:mgatv' does.
I'll give it another try in that case.
Marko
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
