4 ms·

>GPU accelerated video encoding/decoding is done largely via special fixed function hardware not GPGPU so there really isn't a relation between the links and th

>GPU accelerated video encoding/decoding is done largely via special fixed function hardware not GPGPU so there really isn't a relation between the links and the statements CUDA(NVENC/NVDEC), AMF, OpenCL are listed on the FFMpeg chart I mentioned and linked to. HW Accel might use different compute unit for its function, but GPGPU API is also being used for that nevertheless. Perhaps HW Accel is not the best example for sighting the need gap for universal GPGPU API or its implementation as OP talks about porting GPGPU API for a non-supported platform; What would be the right example? P.S. I stand corrected on implying Radeon HD 6000 couldn't encode in HW Accel due to API mess, where as it was missing ASIC. Thanks.

zamadatix 6y ago
NVENC/NVDEC are not CUDA, they are API's for accessing the fixed function hardware on Nvidia GPUs. Same with AMF, just for the AMD fixed function hardware. VAAPI/VDPAU/DX*/others in the chart with the exception of OpenCL are OS or cross platform APIs used for abstracting over access to fixed function video decode from many vendors without needing to target each vendor individually. Again, nobody is using any of these APIs for GPGPU for video encode/decode, it performs horribly. The only GPGPU library in that chart is OpenCL, used for accelerating custom video filter effects like blur. The table says OpenCL is supported on Linux, Windows, Mac, and Android devices (with GPUs capable of GPGPU) for Intel, AMD, and Nvidia. The Pi isn't supported because the GPU isn't capable enough. That leaves the only capable platform not covered by that could be as iOS (walled garden reasons). I.e. I'm not seeing the gap you keep referring to for GPGPU APIs, just a task (video coding) that doesn't work well on general purpose hardware. As for ZLUDA, why is it needed then? CUDA was and is extremely popular as Nvidia has been at the forefront of GPGPU (hardware and software) for over a decade pushing CUDA along the way. OpenCL didn't even get comparable until 5 years after CUDA kicked off. As a result there is a large amount of CUDA code out there that people don't want to rewrite just to make it portable. Hence projects like ZLUDA for Intel which does it transparently and ROCm from AMD which helps automate the porting of code.
- Abishek_Muthian 6y ago
  >NVENC/NVDEC are not CUDA, they are API's for accessing the fixed function hardware on Nvidia GPUs. Not necessarily, NVENC can use CUDA cores for hardware acceleration too for certain features[1] - >HEVC encoding also lacks Sample Adaptive Offset (SAO). Adaptive quantization, look-ahead rate control, adaptive B-frames (H.264 only) and adaptive GOP features were added with the release of Nvidia Video Codec SDK 7.These features rely on CUDA cores for hardware acceleration. >Nvidia Video Codec SDK 8 added Pascal exclusive Weighted Prediction feature (CUDA based). Weighted prediction is not supported if the encode session is configured with B frames (H.264). [1]https://en.wikipedia.org/wiki/Nvidia_NVENC https://en.wikipedia.org/wiki/Nvidia_NVENC
  - zamadatix 6y ago
    Point of note - using "CUDA Cores" is not the same as using the "CUDA API", particularly from the app's view as it's all behind the NVENC API anyways. But yes, these conditionals are what I was referring to when I said "GPU accelerated video encoding/decoding is done __largely__ via special fixed function hardware" i.e. the fixed function hardware does >95% of the compute work which is what makes it viable.

zamadatix 6y ago

NVENC/NVDEC are not CUDA, they are API's for accessing the fixed function hardware on Nvidia GPUs. Same with AMF, just for the AMD fixed function hardware. VAAPI/VDPAU/DX*/others in the chart with the exception of OpenCL are OS or cross platform APIs used for abstracting over access to fixed function video decode from many vendors without needing to target each vendor individually. Again, nobody is using any of these APIs for GPGPU for video encode/decode, it performs horribly. The only GPGPU library in that chart is OpenCL, used for accelerating custom video filter effects like blur. The table says OpenCL is supported on Linux, Windows, Mac, and Android devices (with GPUs capable of GPGPU) for Intel, AMD, and Nvidia. The Pi isn't supported because the GPU isn't capable enough. That leaves the only capable platform not covered by that could be as iOS (walled garden reasons). I.e. I'm not seeing the gap you keep referring to for GPGPU APIs, just a task (video coding) that doesn't work well on general purpose hardware. As for ZLUDA, why is it needed then? CUDA was and is extremely popular as Nvidia has been at the forefront of GPGPU (hardware and software) for over a decade pushing CUDA along the way. OpenCL didn't even get comparable until 5 years after CUDA kicked off. As a result there is a large amount of CUDA code out there that people don't want to rewrite just to make it portable. Hence projects like ZLUDA for Intel which does it transparently and ROCm from AMD which helps automate the porting of code.

Abishek_Muthian 6y ago
>NVENC/NVDEC are not CUDA, they are API's for accessing the fixed function hardware on Nvidia GPUs. Not necessarily, NVENC can use CUDA cores for hardware acceleration too for certain features[1] - >HEVC encoding also lacks Sample Adaptive Offset (SAO). Adaptive quantization, look-ahead rate control, adaptive B-frames (H.264 only) and adaptive GOP features were added with the release of Nvidia Video Codec SDK 7.These features rely on CUDA cores for hardware acceleration. >Nvidia Video Codec SDK 8 added Pascal exclusive Weighted Prediction feature (CUDA based). Weighted prediction is not supported if the encode session is configured with B frames (H.264). [1]https://en.wikipedia.org/wiki/Nvidia_NVENC https://en.wikipedia.org/wiki/Nvidia_NVENC
- zamadatix 6y ago
  Point of note - using "CUDA Cores" is not the same as using the "CUDA API", particularly from the app's view as it's all behind the NVENC API anyways. But yes, these conditionals are what I was referring to when I said "GPU accelerated video encoding/decoding is done __largely__ via special fixed function hardware" i.e. the fixed function hardware does >95% of the compute work which is what makes it viable.