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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
