[FFmpeg-devel] [PATCH v2] fbdetile cpu based framebuffer layout detiling v02

[C Hanish Menon]

Hi Lynne,

Thanks for your thoughts. My thoughts I have embedded below

On Mon, Jun 29, 2020 at 6:32 PM Lynne <dev at lynne.ee> wrote:

> Jun 28, 2020, 22:40 by hanishkvc at gmail.com:
>
> > Hi Mark,
> >
> > **** hwdownload vs separate filter
> >
> > True, for kmsgrab use-case one could potentially do this transform as
> part
> > of the drm_transfer_data logic (which currently mmaps and does a linear
> > copy, if even I remember correctly).  But like what I had mentioned in my
> > previous email, as this is done on the cpu side, if one wants to capture
> > very large framebuffers (say 4K or 8K at high fps), it could impact the
> > performance to some extent, so in such a situation decoupling the capture
> > from detiling, allows one to capture the screen at a very high resolution
> > without worrying about detiling and then handle detile in a offline /
> > separate pass manner.
> >
>
> I too think the filter must be done during hwdownload. That's the only
> place
> where it fits, since the tiling is known, and also the intent to access
> the buffer
> is known.
> We should not be outputting raw, tiled data in the first place and if speed
> really is necessary the detiling can be SIMD'd to speed it up
> significantly.
>
>
Do note that if one uses kmsgrab currently it will be outputting raw tiled
data only, if the underlying framebuffer is tiled. So it is not a new
behaviour, but what exists currently.

And as I had mentioned before, if we embed this logic into hwdownload, then
it can be used only when capturing using hardware context, while by keeping
the logic as a separate filter, the end user has the flexibility to use it
as they may find suitable for their situation. Also the overhead added by
the separate filter to the path is minimal.

Isn't the whole idea of unix kiss principle and piping as well as filter
chaining in the first place to have each logically independent | self
contained functionality as its own and give the user the freedom to mix and
match things the way they want for their end use. And this definitely
follows that.


>
> > NOTE1: Also as a side note, I dont think the existing logic is currently
> > fetching the format modifier of the actual frame buffer, I think it gets
> > set to NONE type by default and remains like that, unless user passes the
> > format_modifier argument, but I could be wrong in this understanding of
> > mine, as I have only gone through the code flow quickly once and also as
> I
> > am in alien territory in some sense at one level.
> >
>
> kmsgrab might not, but other APIs certainly do.
> Also, we don't top post on this mailing list.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



-- 
Keep ;-)
HanishKVC