On Tue, Dec 16, 2003 at 12:45:48PM -0800, Trent Piepho wrote: > On Tue, 16 Dec 2003, Richard Ellis wrote: > > > 6 or 8GB/s L2. The cache size is 256k/CPU, 64k L1. At 550MB/s, > > > it SHOULD be able to push enough to keep the frames encoding at > > > 100% CPU, in theory. > > > > Yes, but just one 720x480 DVD quality frame is larger than 256k > > in size, so a 256k cache per CPU isn't helping too much overall > > considering how many frames there are in a typical video to be > > A 720x480 4:2:0 frame is about 512KB, at 550MB/sec there is enough > memory bandwidth to encode at about 1000 frames/sec if all you had > to do was read the data. Obviously the encoder runs somewhat > slower than that, so each byte of data must be accessed multiple > times. That's where the cache helps.
With motion estimation each byte would end up being accessed more than once for each new "radius" that was examined. Plus motion estimation is between at least two frames, so we are dealing with at least about 1M of data to be accessed eventually in the course of encoding one frame. > > Of course, Andrew would be much better suited to discuss > > mpeg2enc's memory access patterns during encoding, which > > depending on how it does go about accessing memory can better > > make use of the 256k of cache, or cause the 256k of cache to be > > constantly thrashed in and out. > > I seem to recall that one of the biggest performance bottlenecks of > mpeg2enc is they way it accesses memory. It runs each step of the > encoding processes and en entire frame at a time. It's much more > cache friendly run every stage of the encoding process on a single > macroblock before moving on the to next macroblock. In that case it will kill the majority of the performance benifit provided by the caches, because there's very little locality of reference for the cache to compensate for. It moves through at least 512k for pass one, then through the same 512k again for pass two, but the data in the cache is from the end of the frame, and we are starting over at the beginning of the frame. Massive cache thrash in that case. Memory bandwidth becomes a much more limiting factor. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
