On Mon, Apr 17, 2017 at 2:51 PM, Timo Rothenpieler <t...@rothenpieler.org> wrote: >>> I'm generally in favor of adding CUDA based filtering, there's a lot of >>> nice stuff that could be done that way. >>> >>> But there is one big issue with this approach: >>> >>> Having to run a .bat file prior to building isn't really nice, and not >>> something I and some other people on IRC would like to see in ffmpeg. >>> >>> Instead, it would be nice if configure/make would learn how to handle >>> .cu files, converting them straight to an object-file. >>> My idea for this would be to teach the Makefiles about .cu files, and >>> using a shell script as their compiler. >>> That script can then call nvcc and include the ptx2c functionality, and >>> additionally also calls the designated C compiler, so for the build >>> system it converts .cu to .o. >>> >>> Also, due to these kind of filters having to include cuda.h, they need >>> to be put behind --enable-nonfree in configure. >>> >>> That's what I have in mind so far. I didn't have time for a full review >>> of the code yet, so can't say much about the filter itself. >> >> >> I'm against. Building the "script" seems pretty terribly complicated, >> and adding generated code is usually not what we do in this project. >> This is probably done better with a d3d11 video scale filter, although >> I'm not sure about the tradeoffs yet. > > > That's exactly what I said though? Making configure/make generate the code > at build time, so the generated code is not in the repo, only the actual .cu > file. > > One problem with that is, that nvcc require cl.exe on Windows, it doesn't > work with gcc. So that would limit it to MSVC builds on Windows, which is > fine with me. >
FWIW there are non-nvcc cuda compilers that run on Windows, like clang. http://llvm.org/docs/CompileCudaWithLLVM.html _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
