Hi all, Gerd Knorr wrote: <largish SNIP> > > Comments? Anything else we should change? > > Gerd
I just came across the following post while digging the archives: https://listman.redhat.com/mailman/private/video4linux-list/2002-May/012899.html ( Text is quoted below ). Do you think it might be useful to add some mechanism to request buffers with partial frames/fields? May userspace do in-cache image transformations this way, or does schedule() clear the cache anyway most of the time? Perhaps some investigation is required in this area ( Or I just missed the point ... )? Regards, Norbert ------ > [V4L] Linux Codec API > Alan Cox [EMAIL PROTECTED] > Tue, 14 May 2002 06:38:21 -0400 (EDT) > > * Previous message: [V4L] Linux Codec API > * Next message: [V4L] Linux Codec API > * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > >> Which exact part should be cache optimized? What about optimizations for > > You need to be aware of the cache at all time. The L1 cache is about 70 > times faster than main memory, L2 about 9 times faster. > >> the most difficult. If you really want to rip, use the SSE2 and MMX or >> 3dNow! instruction sets and hand-code the expensive sections. But that sort >> of coding takes a while, and all I want is an interchangeable codec system in >> place now so I can play around with it. > > Thing the bigger picture, > > Lets take > > MPEG2->YUV->Filter->CU30 > > you don't want to > > copy entire image into YUV format start->end with the end > kicking the start out of the cache. > filter on cold cache > do cu30 from cold cache > > You want to do > > foreach(tile) > mpeg2 decode tile, filter time, cu30 tile all in L1/L2 > > >> If you really want performance then you need to be writing directly to or >> reading from video memory, and using the video card to do hardware blitting > > Out of date. On a modern AGP card you want the card to do the fetches, > clips and overlaying. You certainly don't want to write to video ram > >> Alan, it seems you are jumping to optimization before a system is even in >> place. Thanks for the heads up about xine, though. I will look through it >> tonight. > > The danger is in designing a system that can't be made to go fast. Tiling is > a very well established graphics technique > >> About half of my senior project would have been done already if we had direct >> show in linux (Actually, that was about 99% of it). > > Nice. > >> system. Data goes in one end of the filter and comes out another end of the >> filter compressed or decompressed. The scaling and conversions could just be >> added stuff that looked (to an application) just like another codec (which >> scaling could be though of as really simple compression/decompression). Chris > > Agreed. > > > > _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
