[FFmpeg-devel] [PATCH 1/2] libavutil/libavfilter: add opencl wrapper to ffmpeg

[Wei Gao]

2013/3/26 Thilo Borgmann <thilo.borgmann at googlemail.com>

> Am 25.03.13 13:03, schrieb Wei Gao:
> > 2013/3/25 Michael Niedermayer <michaelni at gmx.at>
> >
> >> On Mon, Mar 25, 2013 at 10:17:20AM +0800, Wei Gao wrote:
> >>> 2013/3/25 Michael Niedermayer <michaelni at gmx.at>
> >>>
> >>>> On Sun, Mar 24, 2013 at 08:00:46PM +0100, Michael Niedermayer wrote:
> >>>>> On Sun, Mar 24, 2013 at 06:40:27PM +0100, Stefano Sabatini wrote:
> >>>>>> On date Sunday 2013-03-24 19:55:00 +0800, Wei Gao encoded:
> >>>>>>>
> >>>>>>
> >>>>>>> From ab91c74fa166f557eadb39ab399d7ba667b91340 Mon Sep 17 00:00:00
> >>>> 2001
> >>>>>>> From: highgod0401 <highgod0401 at gmail.com>
> >>>>>>> Date: Sun, 24 Mar 2013 19:20:16 +0800
> >>>>>>> Subject: [PATCH 1/2] add opencl wrapper to ffmpeg
> >>>>> [...]
> >>>>>
> >>>>>>> +static int access_binaries(cl_device_id *device_ids, int
> >>>> numdevices, const char *cl_file_name, FILE **fhandle,
> >>>>>>> +                                size_t *binarysizes, char
> >>>> **binaries, int write)
> >>>>>>> +{
> >>>>>>> +    FILE *fd = NULL;
> >>>>>>> +    int status;
> >>>>>>> +    char filename[1024] = {0};
> >>>>>>> +    char cl_name[1024] = {0};
> >>>>>>> +    char devicename[1024] = {0};
> >>>>>>> +    int i;
> >>>>>>> +    for (i = 0; i < numdevices; i++) {
> >>>>>>> +        if (device_ids[i] != 0) {
> >>>>>>> +            status = clGetDeviceInfo(device_ids[i],
> >>>>>>> +                                     CL_DEVICE_NAME,
> >>>>>>> +                                     sizeof(devicename),
> >>>>>>> +                                     devicename,
> >>>>>>> +                                     NULL);
> >>>>>>> +            if (status == CL_SUCCESS) {
> >>>>>>> +
> >>  av_strlcpy(cl_name,cl_file_name,sizeof(cl_name));
> >>>>>>> +                snprintf(filename,
> >> sizeof(filename),"./%s-%s.bin",
> >>>> cl_name, devicename);
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>> +                    if (binarysizes[i] != 0) {
> >>>>>>> +                        output = fopen(filename, "wb");
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>> +                        }
> >>>>>>> +                        fwrite(binaries[i], sizeof(char),
> >>>> binarysizes[i], output);
> >>>>>
> >>>>> theres no gurantee that you have write permission in the current
> >>>>> directory or in any directory.
> >>>>> Also its not nice from a library to drop files in the current
> >>>>> directory unrequested
> >>>>
> >>>> also, while i didnt read the whole file read/write code it appears
> >>>> to me that files are read and executed from the current directory
> >>>> this is not safe, someone could have placed a mallicious file there
> >>>>
> >>> The file is use to save compile informations of OpenCL kernels in
> ffmpeg.
> >>> Because OpenCL kernels is compiled in the runtime, and the compile time
> >>> will be longer if there are more OpenCL kernels.If ffmpeg compile
> kernel
> >>> every time, it will cost a long time in compiling every time.So we
> record
> >>> the compile information the first time. And ffmpeg will load the file
> and
> >>> run kernel without compile. It can save much time.
> >>
> >> This is not a compile cache vs. security argumentation.
> >> security is a requirement.
> >> If we can implement a secure compile cache that would be ideal.
> >> But if its not secure then a insecure cache is not an alternative.
> >>
> >> Also for such a cache you need a directory where to place the files
> >> the current directory is not ok. The directory path needs to be
> >> configureable at build time, if no path is configured the code should
> >> not read or write any excutables.
> >> The path also needs to support $HOME or something like that.
> >> And accessing the cache needs to work correctly if, 2 or more ffmpeg
> >> processes access the cache at the same time.
> >> also the cache must work when newer code has become available, that
> >> is a user might have updated his ffmpeg to one with newer opencl code.
> >> or updated opencl itself
> >>
> >> Should we need to add a configure option to this? I don't konw how to
> get
> > the configured patch, is there any examples?
>
> We should consider to keep the kernels in the library. Either as build-time
> compiled data or as plain text strings.
>
> Also the usual kernel is small and the compilers are fast. I doubt that
> on-the-fly compiling of the invoked kernels significantly influences the
> processing time of the filter chain processing, even for audio - some
> numbers
> might help to convince me I'm wrong.
>
Hi,

Compiling kernels in runtime because of that the kernel compiled depends on
different GPU platform, The released ffmpeg.exe should compiled the kernel
in different platform, so I think it should compiled in run time.

Thanks
Best regards

>
> -Thilo
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>