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

[Mark Thompson]

On 27/06/2020 20:57, hanishkvc wrote:
> v02-20200627IST2331
> 
> Unrolled Intel Legacy Tile-Y detiling logic.
> 
> Also a consolidated patch file, instead of the previous development
> flow based multiple patch files.
> 
> v01-20200627IST1308
> 
> Implemented Intel Legacy Tile-X and Tile-Y detiling logic
> 
> NOTES:
> 
> This video filter allows framebuffers which are tiled to be detiled
> using logic running on the cpu, into a linear layout.
> 
> Currently it supports Intel Legacy Tile-X and Tile-Y layout detiling.
> THis should help one to work with frames captured (say using kmsgrab)
> on laptops having Intel GPU.
> 
> Tile-X conversion logic has been explicitly cross checked, with Tile-X
> based frames. However Tile-Y conv logic hasnt been tested with Tile-Y
> based frames, but it should potentially do the job, based on my current
> understanding of the Tile-Y layout format.
> 
> TODO1: At a later time have to generate Tile-Y based frames, and then
> cross check the corresponding logic explicitly.
> 
> TODO2: May be use OpenGL or Vulcan buffer helper routines to do the
> layout conversion. But some online discussions from sometime back seem
> to indicate that this path is not fully bug free currently.
> ---
>   Changelog                 |   1 +
>   doc/filters.texi          |  62 ++++++++
>   libavfilter/Makefile      |   1 +
>   libavfilter/allfilters.c  |   1 +
>   libavfilter/vf_fbdetile.c | 309 ++++++++++++++++++++++++++++++++++++++
>   5 files changed, 374 insertions(+)
>   create mode 100644 libavfilter/vf_fbdetile.c

For your kmsgrab use-case I think you are doing this in the wrong place.  There is already a copy during the download step (the hwdownload filter before this), and that does know what the tiling mode 
is such that it could detile transparently without a need for an extra filter doing another copy.  See drm_transfer_data_from() in libavutil/hwcontext_drm.c, which currently just does the linear copy 
you observe regardless of the format modifier on the input buffer.

Unrelated to the previous point, does the dependence of the actual layout of the X and Y tiled formats on the exact model of GPU in use cause any problems here?  If the layout is actually the same on 
everything people might use nowadays then it's probably fine; if that isn't true then maybe it needs some extra check.

- Mark