[FFmpeg-devel] [PATCH v3] fbdetile cpu based detiling of framebuffers v03

[Lynne]

Jul 1, 2020, 17:37 by hanishkvc at gmail.com:

> Hi Lynne,
>
> On Wed, Jul 1, 2020 at 3:37 PM Lynne <dev at lynne.ee> wrote:
>
>> Jun 29, 2020, 18:58 by hanishkvc at gmail.com:
>>
>> > v03-20200629IST2208 fbdetile
>> >
>> > Added a generic detiling logic, which can be easily configured to
>> > detile many different tiling schemes.
>> >
>> > The same is inturn used to detile Intel Tile-Yf layout.
>> >
>> > NOTE: This is a full patch, it contains the previous versions also
>> > in it.
>> >
>> > 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,
>> > as well as the newer Intel Tile-Yf layouts.
>> >
>> > THis should help one to work with frames captured (say using kmsgrab)
>> > on laptops having Intel GPU. This can be done live while capturing
>> > itself, or it can be applied later as a seperate pass.
>> >
>> > Tile-X conversion logic has been explicitly cross checked, with Tile-X
>> > based frames. However Tile-Y and Tile-Yf conv logics havent been tested
>> > with Tile-Y | Tile-Yf based frames, but it should potentially get the
>> > job done, based on my current understanding of these layout formats.
>> >
>> > TODO1: At a later time have to generate Tile-Y|Yf 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.
>> >
>>
>> Still not happening, I'd like to see this done properly with hwdownload.
>> While what you
>> have works as a hack, we're not interested in hacks but something that
>> works universally.
>> As I said before, it can be easily sped up by a factor of 4 or 8 using
>> SIMD, so its
>> unjustifiable to have this in the codebase as a filter.
>>
> Can you tell me how this is not universal. Rather by embedding it within
> hwdownload, we
> will be making it limited to use from a hwcontext, while keeping it has a
> seperate filter,
> allows one to use it either with a hw context or from any other source. And
> also it gives
> the flexibility to do it live or offline. So not sure in what sense you
> call my current flow
> restricted and a possible embedded within hwdownload one has being
> universal?
>

You have absolutely no idea what tiling is used outside of the hwcontext.
No, you can't be clever and just say "write it in the filename".
To do this properly, you'll need to add pixel formats for each tiling format. Which we're
definitely not doing for very low level device specific layouts. Further still, you'll need to
add support for that in libswscale (good luck), because its swscale that will be doing the
conversions, not a filter. Filters understand pixel formats only. And options are not pixel
formats.
And even if you were to add those pixel formats and support for it in libswscale, an implicit
conversion will take place before encoding anyway since no encoder will understand those
pixel formats. So you'll need to add support for encoding such pixel formats directly
without conversion.
But as I said before, we're definitely not going to accept such pixel formats, let alone
all the rest that would be necessary to do this properly. And its a good thing, because
there's a correct solution which doesn't rely on hacks, is so simple and will work for anyone:
just do the conversion while downloading. We already kind of do something similar for
some hwcontexts, and drm is not special in any way. In fact, I don't think the drm hwcontext
is correct in even allowing downloading or mapping of tiled images. Its just that by chance
it works for linear images and it doesn't check the mapping (because AMD doesn't support
modifiers so you have no idea whether something is linear or not, and the person who wrote
the hwcontext was using AMD at the time).
So really, please integrate this into hwcontext_drm.c.