[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iBook and playing DVDs



On Mon, 2002-05-13 at 22:04, Rogério Brito wrote: 
> On May 12 2002, Michel Dänzer wrote:
> > On Sun, 2002-05-12 at 14:34, Rogério Brito wrote:
> 
> > > 	All that I can say is that I feel cheated. :-(
> > 
> > Well, the actual movies shouldn't be interlaced.
> 
> 	Well, I read that also in Ben's reply and got surprised, since
> 	without exception all DVDs that I have seen to this day are
> 	interlaced.

Sounds like bad encodings. The original movies as shown in theaters obviously
aren't interlaced so if a DVD is that's purely artificial.


> > Rumour has it that the current one in benh's tree is 2.2 except the
> > version is wrong (somebody posted a patch to 'fix' the version number to
> > linuxppc-dev), but if I were you I'd wait for confirmation from benh
> > before relying on that. :)
> 
> 	Yes, I went to hunt that message and actually recompiled a new
> 	kernel with the new version, but for some reason, I couldn't
> 	make dri work with the X binaries from your site.

What happened? My suspicion is that the other guy only tried with the 4.2 3D
driver, where 2.1 or 2.2 doesn't really make a difference.


> > > 	Perhaps the r128 module isn't being maintained?
> > 
> > It is, kinda, by XFree86 and DRI. Both their CVS repositories have
> > the 2.2 version, just nobody has updated the Linux kernel yet.
> 
> 	I see. I'm crossing my fingers for this update to happen
> 	soon. :-)

It's being worked on, see the dri-devel archives if you're interested.
Meanwhile, for 4.2 you can build the DRM from the XFree86 4.2 CVS branch or
from http://xfree86.org/~alanh/ .


> > > 	What is the problem with publishing the interfaces for that? I
> > > 	thought that ATI were an open-source friendly company. :-(
> > 
> > They are IMHO. Every company seems to be afraid of releasing that
> > kind of information, I have an idea why but people tell me there's
> > no reason...
> 
> 	Could you say what could be the possible reasons for ATI to
> 	not release the specifications? I'd be really interested to
> 	know. I promise that I won't start a flamewar if I don't like
> 	what I read. :-)

My idea is it has to do with certain US laws, but what do I know.

> 	But how "closed" is ATI to specifying the interface to hw
> 	accel of their chips?

They provide docs to interested developers, just not for these features.

> Perhaps an organized petition would help here?

Who knows, but I'd expect the GATOS project to have achieved something in
that case.


> > I'm afraid you'll be disappointed. Seems it was only good for a real
> > 'gain' as a hack on top of 4.1. Now that it's done (more :)
> > correctly, a lot of cycles are still wasted waiting for the DMA
> > transfer to complete.
> 
> 	Well, just using a new X helped performance a bit with xine. I
> 	am hoping that DMA would help more. Any tiny bit would help.
> 
> 	And is the CPU stalled when the DMA transfer is being
> 	performed? I'd say no, given my limited understanding of the
> 	matter (otherwise, there would be not improvement in doing DMA
> 	in the first place, right?)

Right, but with a catch: the DMA transfer must complete before the image can
displayed. Right now, this is ensured by waiting for the DMA engine to go idle,
which is basically implemented as a busy loop in the DRM. So while the transfer
will be faster than with plain memcpy, a lot of CPU cycles are wasted.

> 	If it is not, then even lowering the CPU consumption would
> 	help, as there could be more processes decoding the video,
> 	right? Or would the actual video output be slower, in general?

Should be at least as fast, just hardly significantly faster yet.

> 	OTOH, perhaps the bottleneck being how the video operations
> 	are slower may be the reason why mplayer's video out benchmark
> 	with X 4.2 was so much higher than with X 4.1?

I don't understand. What does that benchmark measure and how do the results
compare?

> > Using an interrupt might help there.
> 
> 	I don't understand this, sorry. :-)

The chip could issue an interrupt when the DMA transfer is complete so
the CPU could do something useful while it's in progress.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


--
To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: