Re: [FFmpeg-devel] [PATCH 05/16] avutil: add common code for nvtegra

[averne <averne381@gmail.com>]

Le 05/06/2024 à 22:29, Mark Thompson a écrit :
> On 30/05/2024 20:43, averne wrote:
>> This includes a new pixel format for nvtegra hardware frames, and several objects for interaction with hardware blocks.
>> In particular, this contains code for channels (handles to hardware engines), maps (memory-mapped buffers shared with engines), and command buffers (abstraction for building command lists sent to the engines).
>>
>> Signed-off-by: averne <averne381@gmail.com>
>> ---
>>  configure                  |    2 +
>>  libavutil/Makefile         |    4 +
>>  libavutil/nvtegra.c        | 1035 ++++++++++++++++++++++++++++++++++++
>>  libavutil/nvtegra.h        |  258 +++++++++
>>  libavutil/nvtegra_host1x.h |   94 ++++
>>  libavutil/pixdesc.c        |    4 +
>>  libavutil/pixfmt.h         |    8 +
>>  7 files changed, 1405 insertions(+)
>>  create mode 100644 libavutil/nvtegra.c
>>  create mode 100644 libavutil/nvtegra.h
>>  create mode 100644 libavutil/nvtegra_host1x.h
>
> I don't think it is reasonable for all of this to be public API surface of ffmpeg.
>
> A separate library containing the headers and exposing some set of functions like this might make more sense.
>
> If this has to be in ffmpeg then it really needs to all go in one library (libavcodec I guess) so that it's not exposing all this internal detail in the public API.
>
> Thanks,
>
> - Mark

Sorry for the delayed answer.
I'm considering writing a library to abstract all those platform 
details (buffer allocation, channel management, job submission, command 
buffers, synchronization, frequency scaling), essentially replacing 
all of the nvtegra.c and much of hwcontext_nvtegra.c code. The library 
would also handle frame transfers, since that code is somewhat low-level 
and multiple methods can be used depending on the situation (VIC on 
Tegra platforms, the GPU copy and 2D engines, or CPU copies on platforms 
with unified memory).
This would also shield FFmpeg from API changes, though I don't think 
this was ever an actual problem.
The FFmpeg-side code would remain in charge of building the metadata 
sent to the decode hardware, but multiple platforms could be supported 
with very minimal #ifdef juggling. I'm especially interested in discrete 
GPUs on linux.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".