[Mplayer-advusers] Bug? Anomalous CPU usage when playing HDTV clips.

[D Richard Felker III]

On Tue, Apr 13, 2004 at 09:14:09AM -0700, John Stebbins wrote:
> On Mon, 2004-04-12 at 22:33, D Richard Felker III wrote:
> > On Mon, Apr 12, 2004 at 04:29:05PM -0700, John Stebbins wrote:
> > > On Mon, 2004-04-12 at 13:06, D Richard Felker III wrote:
> > > > > The driver does use a command to the hardware that says 
> > > > > "switch buffers at next vblank".  But the way the driver was
> > > > > implemented, they are only using one buffer at a time in this code
> > > > > path (though 2 are allocated).  Before copying data into the next
> > > > > buffer, they always wait for the previous buffer to become free. They
> > > > > sit in a busy wait loop reading a status register until the
> > > > > previous operation is complete.  Then they switch "current" buffers,
> > > > > fill the "current" buffer, issue the command to refresh on vsync and
> > > > > return.
> > > > 
> > > > Ah, this is brain damaged. The only correct way is triple-buffering.
> > > > Can you fix the driver to triple-buffer so that it doesn't matter?
> > > > 
> > > > Rich
> > > > 
> > > 
> > > Could you explain your triple-buffering idea in more detail.
> > > I'm afraid I'm not picturing what you have in mind.
> > 
> > Cycle between 3 different buffers instead of just 2. Then you don't
> > have to wait for the buffer switch before drawing the next buffer.
> > 
> 
> You can't be sure of that.  For example, when the -benchmark option
> of mplayer is used, frames are displayed as fast as they can be
> decoded.  If decoding is fast enough you will get more than 3 display
> requests per vsync.

Yes, but that's stupid/irrelevant. As long as you're playing movies
correctly, no special trickery is needed with triple buffering.

Rich