Remove OpenCL support

added 7 commits

• 6b1fae5a...b684ebe0 - 6 commits from branch videolan:master
• 1b126262 - Remove OpenCL support

Compare with previous version

Why? It is cool!

1. It has not been maintained for more than 7 years (last change was in 2014). And not because the code is so perfect that there are no bugs and there is nothing to improve (in fact, it was never even in production ready state), but simply because nobody cares, since in fact almost no one uses it (and its use has never been recommended).
2. Its presence prevents changes of general lookahead code because it should be changed in sync with OpenCL lookahead code which nobody wants to touch. And so, it harms development of core functionality.
3. It is not cool, it is just a gimmick. It was just an experiment (Proof of Concept) on a hot topic at that time, which, IMHO, failed (well, maybe except as a marketing tool). If you are not satisfied with the encoding speed of x264 on CPU-only than it makes more sense to look towards fully hardware accelerated encoding i.e. QuickSync / NVENC / AMF / VCE / etc. As history of the last 10 years shows, all hybrid codecs have failed and are long forgotten, as they were usually just a temporary solution until the development of an acceptable fully hardware accelerated codecs.

fully hardware accelerated encoding i.e. QuickSync / NVENC / AMF / VCE / etc.

I know everything about -hwaccel cuda and hevc_nvenc, inluding lossless hevc_nvenc and b frame as reference with middle mode and whatever, for that last one I made it working in ffmpeg. And also nvidia-patch anout nvfbc and > 2 streams encoding. And HDR10+ stuff with Nvidia.

all hybrid codecs have failed and are long forgotten

Flac on OpenCL and CUDA and JPEG 2000 on CUDA, just to name a few. And that is not even talking about insane amount of tools from Wolfram Mathematica to Amber MD to gnuradio.

Also, OpenCL 3.0 was just activated in Nvidia last month. 465+ driver.

Also WE IN GOOGLE/Chromium do everything on GPU. I mean besides javascript. But who knows, am I right?

It is not cool, it is just a gimmick

Why then we mention it? https://ffmpeg.org/pipermail/ffmpeg-user/2018-April/039610.html

And have separate code to support it in x264 for it? https://trac.ffmpeg.org/wiki/Encode/H.264

fully hardware accelerated encoding i.e. QuickSync / NVENC / AMF / VCE / etc.

I know everything about -hwaccel cuda and hevc_nvenc, inluding lossless hevc_nvenc and b frame as reference with middle mode and whatever, for that last one I made it working in ffmpeg. And also nvidia-patch anout nvfbc and > 2 streams encoding. And HDR10+ stuff with Nvidia.

Good for you.

all hybrid codecs have failed and are long forgotten

Flac on OpenCL and CUDA and JPEG 2000 on CUDA, just to name a few.

OK, I should have been less categorical and precise, I meant: "almost all hybrid video codecs". And by video codecs I mean inter encoding i.e. with ME and RDO.

And that is not even talking about insane amount of tools from Wolfram Mathematica to Amber MD to gnuradio.

Also, OpenCL 3.0 was just activated in Nvidia last month. 465+ driver.

Also WE IN GOOGLE/Chromium do everything on GPU. I mean besides javascript. But who knows, am I right?

Don't mix up general use of OpenCL/CUDA for computation and specific use case for video codecs. OpenCL/CUDA have a lot of use cases where they are good like renders (Blender), image filters (Photoshop) and others. But it is not the silver bullet.

It is not cool, it is just a gimmick

Why then we mention it? https://ffmpeg.org/pipermail/ffmpeg-user/2018-April/039610.html

And have separate code to support it in x264 for it? https://trac.ffmpeg.org/wiki/Encode/H.264

I can't answer for the actions of other people.

P.S. Meaning of gimmick

added 17 commits

• 1b126262...66a5bc1b - 16 commits from branch videolan:master
• a758c48e - Remove OpenCL support

Compare with previous version

I understand your point in the sense that you wanna introduce changes in the way lookahead works and you can't due to the opencl support, however I'm not really in favour of removing it. I know that it hasn't been maintained for years, but despite it being a proof of concept, it actually helps offloading the CPU and speeding things up a bit. I know that benchmarks sometimes showed little to no speed increase at all, but there are some use cases in which it does actually help. For instance, Here at Sky we have several servers re-encoding XDCAM-50 and XDCAM-85 masterfiles into low bitrate consumer H.264 files for the web and since the CPU is responsible not only of encoding the file but also of deinterlacing and resizing the chroma (yv16 to yv12) through Avisynth in an automated fashion, using --opencl in x264 and making use of the NVIDIA Quadro P4000 actually helped and I've gained 12 FPS on every encode (generally there are multiple encodes on a single server, up to 20). The cool thing about this is that even though using NVEnc would be faster, the NVIDIA hardware encoder ain't nearly as good as x264, especially at low consumer-tier bitrates, which is why I have always leaned towards x264. I don't think opencl support should be removed, if anything I'd like to see it implemented in x265 too! I guess we should have an online discussion about x264 and Opencl, though, and ask users whether they would like to keep it or not and see if people are actually really using it (and something tells me that lots of people are indeed using it).

added 11 commits

• a758c48e...0bb85e8b - 10 commits from branch videolan:master
• 4d66a25f - Remove OpenCL support

Compare with previous version

Meanwhile JPEG 2000 on CUDA became part of Nvidia SDK. LOL! https://docs.nvidia.com/cuda/nvjpeg2000/userguide.html

Of course it has, 'cause nowadays most content providers work with IMF packages, so it's just very handy for them to have NVEnc do it for them rather than using the CPU. This is what they generally encode:

So again, it makes sense to have the encoder in the GPU rather than in the CPU. Anyway, this has nothing to do with x264. Back to x264, Anton has been very clear: there are some changes that need to happen in the lookahead section of the code that will be in conflict with the opencl implementation, so unless someone is gonna pick opencl up and properly support it, when the time will be inevitable, he will merge this commit and it's gonna be game over, which is why I very much hope that someone will pick it up and maintain it, but honestly, without Steve Borho (the multicoreware guy), I don't really see the public picking this up and keeping development ongoing...

That does not use NVDEC. Nvdec/enc is separate selicon logic. That is just written in CUDA, no NVENC or NVDEC. I was just laughing at the irony that nvidia did implement it in CUDA language (so AMD can run it too with special translators). The one linked above was not from nvidia.

there are some changes that need to happen in the lookahead section of the code that will be in conflict with the opencl implementatio

Oh, standard "not maintained code" argument. Except this is not linux kernel, so does not make any sense. We are all programmers here, it is possible to write new lookahead code without touching anything in OpenCL.

the multicoreware guy

It would be also nice to port x264 to CUDA... That would be actually insane speed ups. Even if no super paralell stuff is involved.

Ah, I didn't know it was entirely written in CUDA. That's nice, then. ;) About the "not maintained code" thing, look, I'm with you on this, the last thing I'd like would be to see opencl removed, so if there's a way to implement the changes in the lookahead without braking the opencl hardware acceleration, so be it, that would be great, but I trust Anton, he knows the code better than anyone here 'cause he worked with Steve back in the days to implement the whole thing, so if there's a way, he'll find it and if there isn't, he will tell us.

Lastly, about CUDA, yeah, there's been a recent shift in the Avisynth community towards offloading some computations to the GPU via CUDA. At the very beginning it was just the stuff made by Donald Graft, but now it's much more widespread ever since Avisynth Neo was merged so much so that we have functions like OnCPU() and OnCUDA() to use before we call filters etc. Using CUDA provided a whole lot of sense in the frameserver and helped with computational costs, especially at a time when 16bit UHD post-processing is a real thing. I wonder whether that would be useful in x264 as well, but I guess this is another story. At the time, opencl was picked 'cause it was an open standard, so it was possible to make use of it everywhere, not just on NVIDIA GPUs and indeed nowadays if I use --opencl on an NVIDIA GPU or an AMD/ATI GPU or even on an Intel GPU nothing changes and the code gets executed just fine.

Anyway, I don't want to make the topic derail any further, but it's nice to see that there are people who care about hardware acceleration (not just on Doom9 but also here). :)