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

[C Hanish Menon]

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?



> _______________________________________________
> 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".