Re: iBook and playing DVDs
> I guess that Apple is making false claims about the iBook's
> ability to play DVDs, since my complete collection of DVDs
> (all 4 of them :-) ) show interlacing artifacts in the image,
> even when playing under MacOS X. :-(
>
> All that I can say is that I feel cheated. :-(
Well. A lot of DVDs aren't interlaced. Some are, and then you'll
have interlacing artifacts when playing on LCD, but not when
playing on TV with the proper resultion.
On the other hand, if you're playing on TV, the ATI chip has a pretty
good deinterlacer built in.
The problem with OS X is that it's current versio doesn't have
all of the features OS 9 had regarding setting up the TV output.
MacOS 9 ca, via the control strip, be setup to full resolution
(no black boerders, meaning that a 720x576 PAL will be a _real_
interlaced PAL output), or to a "graphics" mode (deinterlaced).
> On the other hand, according to MacOS X's cpu monitor, playing
> DVDs only use about 50% of CPU time, probably due to use of
> hardware acceleration.
Yes, it's smoother and use less CPU. Actually, the OS X implementation
is of much higher quality than the OS 9 one in this regard, though the
system itself lacks a few options described above.
>> This is probably as good as it gets right now. I don't think you can
>> do better without using the r128's hardware accelerated iDCT and MC.
>
> I feared that. :-(
Well, are we _that_ far ? It might be possible to properly optimise
the IDCT and MC for "normal" PPCs and win enough perfs... and it might
not. But from experience of pre-altivec days, properly hand optimized
graphic code can get a huge perf boost on G3s.
>> vlc has had sound problems for quite a while. Here's what Jack Howarth
>> said re. vlc's audio settings:
>
> Oh, thank you very much for that quote. I guess that it means
> that I am not a complete fool as I think I am for not making
> vlc work correctly. :-)
>
>[High CPU usage during video output]
>> That's essentially because of MTRR on i386. I wouldn't know hard
>> numbers to compare, but at least subjectivly, MTRR helps a lot for
>> the copy to VRAM of the video out data.
>
> Ouch, I miss MTRR. :-(
The current DMA implementation suffers from lack of DMA usage
(meaning time is lost waiting for it to complete) and not properly
working AGP x2 and x4 modes (would speed things up).
I've obtained similar perfs by just doing 64 bits blits using
floating point registers. So there is probably room for improvement
here, especially if we can figure out why almost all ATI chips
tend to lockup when using AGP...
>[XFree86 4.2.0 and DMA]
>> Note that for DMA you need DRI, which needs large amounts of
>> VRAM. So you may only be able to use that in 16-bit mode. I'm
>> usually running in 32-bit mode :(
>
> So, from you comment, I infer that you have an iBook also?
>
> Anyway, I don't mind if I have to use 16-bit mode. If the
> movie is "good enough", then I'm cool with that.
>
> I'd love to get DMA running on this iBook and would appreciate
> if anybody could tell me where I can get a r128 with version
> 2.2, as current benh's kernel only has version 2.1.6
> available. :-(
>
> Perhaps the r128 module isn't being maintained?
>
>> You've got it :-) No, there are a few things that still can be done:
>>
>> - get ATI to open the specs for iDCT and MC in hardware. Won't happen
>> anytime soon.
>
> What is the problem with publishing the interfaces for that? I
> thought that ATI were an open-source friendly company. :-(
They used to be, but they also stopped responding properly to my
emails for some time, that's one reason why the tipb with rage M6
sleep bug (apparently related to a chip HW bug) isn't fixed yet.
>> - optimize a few of the more processor-intensive parts of the algorithms
>> with handcoded ASM. Good luck...
>
> Well, I'm so pissed that I am currently even considering
> learning PPC's assembly for this task. I even downloaded
> Motorola's user guide for the G3. :-( The only problem now is
> lack of time.
You may want to look into one big bootleneck with PPC: memory
transfers. If you can find places where quantity other than full
aligned 32 bits words are moved around, you way get a significant
performance boost by implementing a simple "deblocking" mecanism
via a couple of intermediate registers. This can most of the time
be done entirely in C.
If you find raw memcpy's, you can make sure they are 64 bits aligned
on both source and dest and then use floating point registers to move
64 bits at a time.
> BTW, I'm using the following options to compile the programs I
> am trying:
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>CC="gcc-3.0"
>CFLAGS="-O3 -fomit-frame-pointer -ffast-math -frename-registers \
> -mtune=750 -mcpu=750 -mfused-madd"
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Any suggestions on what else I should use? Perhaps gcc-3.1 is
> a bit better regarding optimizations?
>
>> - use DMA: that should be doable with the right pieces of code.
>
> Well, that is my highest hope right now. I'd love to get a
> kernel with a r128.o that allows DMA to be used.
>
>
>
> Thank you for your comments, Roger...
>
>--
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Rogério Brito - rbrito@iname.com - http://www.ime.usp.br/~rbrito/
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
>--
>To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: