GSoC'22
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user input
libavfilter/allfilters.c: added the filter to it
libavfilter/Makefile: added the filter to it
cuda/cuda_runtime.h: added two math CUDA functions that are used in the filter
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This fixes building with MSVC after
a2a38b1606.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (PVOID volatile *).
Signed-off-by: Martin Storsjö <martin@martin.st>
cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion
guards with an AV_ prefix, although these files are not in an libav*/
path. So change the inclusion guards and adapt the ref file of the
source fate test accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This avoids using the CUDA SDK at all; instead, we provide a minimal
reimplementation of the basic functionality that lavfi actually uses.
It generates very similar code to what NVCC produces.
The header contains no implementation code derived from the SDK.
The function and type declarations are derived from the SDK only to the
extent required to build a compatible implementation. This is generally
accepted to qualify as fair use.
Because this option does not require the proprietary SDK, it does not require
the "--enable-nonfree" flag in configure.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
As part of the update, it is now possible to test 32-bit GCC builds
of AviSynth+ with FFmpeg by using the AVS_WIN32_GCC32 define. Due to
different calling conventions between MSVC and GCC regarding 32-bit
Windows, this is unfortunately necessary.
External headers are no longer welcome in the ffmpeg codebase because they
increase the maintenance burden. However, in the NVidia case the vanilla
headers need some modifications to be usable in ffmpeg therefore we still
provide them, but in a separate repository.
The external headers can be found at
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
Fate-source is updated because of the deleted files, and dynlink_loader.h
license headers were updated with the standard FFmpeg headers.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This removes the XP compatibility code, and switches entirely to SWR
locks, which are available starting at Windows Vista.
This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.
Windows XP is hereby not a supported build target anymore. It was
decided in a project vote that this is OK.
This avoids having to use either "dumpbin -headers" to find out
the current architecture, or pass $ARCH from configure to deduce it.
When configuring with --disable-asm, ARCH is equal to "c", which doesn't
give any indication of what symbol prefix is to be used.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'a37e84be69310cd7de9540c8bc194cb0a6d158ed':
makedef: Add support for identifying the ARM64 machine type
Merged-by: James Almer <jamrial@gmail.com>
* commit '1a7bf48eed806beea7e835b31b06aa6bc94da5da':
makedef: Extend the script for use with mingw tools as well
Merged-by: James Almer <jamrial@gmail.com>
* commit '44aa9105c535471ca9e23796d7ca29b341f47636':
makedef: Fold as much text transformations as possible into the initial dump
Merged-by: James Almer <jamrial@gmail.com>
Since this machine type is 5 chars while the existing ones only
were 3 (which the regexp assumed), the regexp has to be extended
a little.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is invoked by setting the NM and AR variables to the names of
those specific tools. The ARCH variable also needs to be provided,
to choose the symbol prefix (nm doesn't provide any option that
dumps the architecture easily).
Signed-off-by: Martin Storsjö <martin@martin.st>
Windows nvcc + cl.exe produce a .ctx file with CR+LF newlines which
need to be stripped to work with gcc.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This only enables dlls that are packaged with the application to be
loaded. Due to the limitations of WinRT/UWP it is not allowed to load
external/system dlls so this cannot be used as a complete replacement
for normal win32 dll loading.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
