[MPlayer-dev-eng] Adding threaded functionality to mplayer

[D Richard Felker III]

On Mon, Sep 06, 2004 at 04:24:53PM +0100, Ed Wildgoose wrote:
> 
> >Yes, teh copy operation from RAM to the video card is actualy what is
> >limiting everyting. Just do a quick calculation:
> >
> >320*240 pixels * 3 bytes/pixel * 30 frames per second = 6'912'000 bytes/s
> >(CIF RGB)
> >640*480 pixels * 2 byte/pixe * 30 frames per second = 18'432'000 bytes/s
> >
> >Now, the BW you have is anything between 15MB/s to 100MB/s, ie
> >it uses 6% to 120% of your time to just copy data (with the above
> >numbers). And at this time, the CPU is mostly blocked as it cannot
> >access RAM.
> >
> >Note: the 100MB/s is an estimation on my side, i dont have numbers
> >for todays super fast blah blub systems. Is there someone out there
> >who can provide some _real_world_ data on how much BW is available
> >from RAM to graphics memory with current state of the art PC hardware ?
> > 
> >
> 
> Most people have AGP, but someone told me that this is an asynchronous 
> interface...?  Faster to copy in than out...?  Anyway, PCI-X is on the 
> horizon, and this promises to let you do really silly things like use 
> your graphics card as a general purpose DSP processor!  This should be 
> really funky, and the bandwidth will be awesome.  Boards are already 
> available from Asus and others.
> 
> 
> Cutting back to the original point though about threading mplayer.  
> Adding threads is not really about performance, and whoever said that 
> synchronisation became harder was missing the point.  Basically all I 
> was suggesting is that you have one thread displaying video, and one 
> running the audio.  Basically at a high level the video thread prepares 
> a frame and then blocks until the audio thread signals that the video 
> frame is due to be displayed, and effectively yields to the video 
> thread.  Video displays a frame and then blocks again until the audio 
> thread tellis it that it's time to display again.
> 
> In the same way you can have a keyboard loop sending instructions to the 
> other threads about what to play.
> 
> It's quite a simple design compared with the event loop that we have at 
> the moment, effectively you just split main() into a number of chunks 
> and get them all to run in their own loops with appropriate 
> synchronisation back to the main thread for master control.  In practice 
> of course you need to be careful not to have a whole bunch of problems 
> caused by threading, but the top down design becomes very simple.

And very slow!!! Using threads is not acceptable because it can and
will destroy cache coherency. You also waste a lot of time on context
switches. Aside from a few limited cases (mainly calling bad libraries
or poorly designed syscalls), anything that can be done with threads
can be cone with a properly designed state machine. Yes, it's more
"complicated", but that's why good apps are written by wizards and not
java newbies...

Rich