[MPlayer-dev-eng] Re: 32x32 tiled output driver

[Nikolaj]

On Fri, 18 Mar 2005 16:40:23 -0800, Jacob Gorm Hansen <jacobg at diku.dk> 
wrote:

> D Richard Felker III wrote:
>
>>> Is there a performance benefit to using slice rendering? E.g. smaller 
>>> TLB and cache footprint, or what is the motivation for using this 
>>> method over put_image()?
>>
>>
>> Yes, a significant benefit. When decoding video, the main buffer is
>> always kept in system memory in a linear format with nice alignment,
>> because it's needed for decoding the next frame. You can either wait
>> til you finish decoding a frame and copy this whole buffer from memory
>> to the video device, or you can use slices and copy each slice from
>> the l2 cache to the video device. Naturally the latter is a lot
>> faster.
>
> So I am trying to implement slice rendering, but it seems that for 
> RGB/BGR formats draw_slice just gets called with the whole frame? Is it 
> possible to get small (16 px) slices without supporting YUV conversion?

No, typical video frame buffers have YUV format, and slices accesing them. 
(not sure about swscale)
However, yuv->rgb conversion don't needs a whole frame, and can quite 
simply be done for yuv slices.
Or, tiles.
So, after you get decoded yuv slice you store it into intermediate buffer
with dimensions width*32. After each second slice, you convert each tile 
 from this buffer right
into video device. Or better not to use this buffer and use just 2 slices 
together - they are continious.
Then you just need to divide rgb conversion process into tiles.
If done right, this conversion takes zero time, because it will be 
shadowed by memory access time.
Richard wrote about it some time ago :)


-- 
Best regards,
  Nikolaj                          mailto:nialpof at pisem.net