[FFmpeg-devel] [PATCH v06 2/5] fbtile helperRoutines cpu based framebuffer detiling

[Lynne]

Jul 5, 2020, 04:57 by hanishkvc at gmail.com:

> Hi Lynne,
>
>
> On Sun, 5 Jul, 2020, 00:53 Lynne, <dev at lynne.ee> wrote:
>
>> Jul 4, 2020, 14:17 by hanishkvc at gmail.com:
>>
>> > Add helper routines which can be used to detile tiled framebuffer
>> > layouts into a linear layout, using the cpu.
>> >
>> > Currently it supports Legacy Intel Tile-X, Legacy Intel Tile-Y and
>> > Newer Intel Tile-Yf tiled layouts.
>> >
>> > Currently supported pixel format is 32bit RGB.
>> >
>> > It also contains detile_generic logic, which can be easily configured
>> > to support different kinds of tiling layouts, at the expense of some
>> > processing speed, compared to developing a targeted detiling logic.
>> >
>>
>> Sorry, but we really cannot afford to have this as part of the public API,
>> which it needs to be if it can be used by lavfi. So its unacceptable in its
>> current form, especially if all parts dependent on it are compile-time
>> options.
>> That's why I suggested merging it all into hwcontext_drm.c
>>
>
>
>
> There is no compile time options which it's users/callers need to
> manipulate to use it.
>
> What I meant by easily configurable is, in future if we want to add support
> for a new (currently unknown to it) tile layout, there is no need to do it
> from scratch. One could just add a new set of boundry conditions with the
> required direction changes, and the generic logic can take care of doing
> the required tile walking. This is no different than say adding a new
> colour format or bit resolution or so to a scaler for example, rather I
> would say much simpler than these.
>
> And once the new definition is added into fbtile. It can be used by any of
> its users without any additional change.
>
> That's how any library or for that matter any code works currently, so not
> sure what's diffrent here that you are objecting to.
>
> Also tile manipulation is a logically independent set of operations which
> can be used by any logic and not just hwcontext_drm, and tiling is nothing
> unique to hwcontext_drm, so it will be better to keep it independent of
> hwcontext_drm, because logically/technically it's independent of it.
>
> Also I seem to be missing something here, what is the technical/... reason
> you don't want a frame buffer tile manipulation logic as a public API, in
> case if it is?
>

Something like this, is like I said, very niche and optionally fixes behavior that shouldn't
ever have been exposed had it not been for the incredibly bad decisions libdrm
made (and we made as well).
And for that, and for not fitting in as any part of any library, I don't want a public API
for this anywhere.

Something like this could belong in libswscale, but that requires not resorting to hacks
and actually implementing tiled pixel formats, which we're definitely not doing.

Hence any patches that actually fix the behavior non-optionally would be what's
accepted.
We're not looking for solutions outside of hwcontext_drm. Like I said, no other API
is that badly designed to give the user access to tiled data. There' no point in having
a generic filter/hwdownload setting because there's nothing other than hwcontext_drm
that would use it properly.

While I'm okay with having the detiling as a separate file, it cannot be exposed via
the public API and any user wishing to detile would have to use the hwcontext API.
And I don't want this as an optional filter either. And no, you can't just duplicate
the tiling code to libavfilter.

Bottom line is, we don't want command-line users to _ever_ see or touch tiled content,
and to do that, you have to make hwcontext_drm.c detile when downloading.