On 18 Feb 2002, Michel [ISO-8859-1] Dänzer wrote:
> On Mon, 2002-02-18 at 19:18, Zdenek Kabelac wrote:
> >
> > I believe this is what is going on:
> >
> > Movie players usually wait for for XFree operation completition by calling
> > XSync. Thus when XSync returns to the user space program there is assumption
> > that all XFree operation has been finished and player continues with
> > handling another frame.
> >
> > However for now it looks like XFree is actually returning sonner than
> > all pending operations (image transfers) are finished - as mplayer
> > is waiting in this stage then usually nothing tragical will happen
> > as long as you have fast enough CPU so mplayer could wait enough time
> > before it will decide it's about right time to decode next frame.
> > (might be simulated in aviplay as well - but as avifile has some
> > threaded prechaching it will show this behaviour instantly and you
> > do not have to turn on any postprocessing level).
> >
> > Aviplay almost immeditally after return from XSync call
> > wakes up decoding thread - if all the memory transfers would be
> > finished by this time everything would be just fine - however
> > if the Xserver is still transfering the memory then there will be
> > noticable slowdown as both operation will be completed slower then
> > they could be if these operation would be running in serial.
> >
> > Quit noticable is this on SMP machine where XFree is accessing memory
> > at the same time as decoder is decoding next frame.
>
> But I still don't understand why _X_ should hog the CPU:
>
> - Without DRI, XvShmPutImage() itself only returns after it has
> memcpy()'d the data
>
> - With DRI, it might be possible that XSync doesn't really wait for the
> DMA transfer to complete (maybe PutImage should set
> info->accel->NeedToSync ?), but then it would be the graphics chip
> still accessing RAM, not X
>
>
> I'm very curious what the solution for this is gonna be. :)
Could it be that X is waiting for the engine to become quiscient ? So if
you scheduled a DMA transfer already it has to busy wait for the card to
finish. Which
a) creates unnecessary PCI traffic
b) wastes time..
The solution to this would be to not submit new frames faster than
graphics card can handle them.
Peter - Am I right in thinking that you have Rage128 card ? Can you write
a simple program to measure just how fast can you pump frames into overlay ?
Vladimir Dergachev
>
>
> --
> Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
> XFree86 and DRI project member / CS student, Free Software enthusiast
>
> _______________________________________________
> Gatos-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
