5 ms·

Excellent effort. Nvidia has become defacto GPGPU hardware vendor due to CUDA, but I wish it was OpenCL or other general API instead. Even Raspberry Pi's VideoC

Excellent effort. Nvidia has become defacto GPGPU hardware vendor due to CUDA, but I wish it was OpenCL or other general API instead. Even Raspberry Pi's VideoCore has OpenCL support[1]. But a look at HW Acceleration support table at FFmpeg[2] shows why GPGPU Platform API is such a mess. But performance benefits are incredible, using VAAPI for FFmpeg to encode 1080p 2560x1080 screen capture at 60fps reduces CPU usage from 90% to 10% on a old corei5 with intel HD 3000; An old laptop could be perfectly used as an encoding machine for streaming just by using HW Acceleration. What's funny is that the laptop also has Radeon HD 6490M with 1GB GDDR5 dedicated memory and it's not supported by VAAPI for encoding! GPGPU API/Platform Support are astonishingly messy. [1]https://github.com/doe300/VC4CL https://github.com/doe300/VC4CL [2]https://trac.ffmpeg.org/wiki/HWAccelIntro https://trac.ffmpeg.org/wiki/HWAccelIntro

zamadatix 6y ago
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. The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. The HD 7000 series introduced it to the family. https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_Feature_Matrix https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_F...
- marmaduke 6y ago
  > The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. Doesn’t this prove the broader point that GPGPU cross platform would benefit everyone? A new codec is written.. and everyone gets to use it not just those with fixed function support.
  - zamadatix 6y ago
    No, it proves fixed function hardware outperforms general purpose hardware for the task it's made for. Without the fixed function hardware the GPU is worse suited for the task than a general purpose CPU.
- Abishek_Muthian 6y ago
  >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

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. The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. The HD 7000 series introduced it to the family. https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_Feature_Matrix https://en.wikipedia.org/wiki/Radeon_HD_6000_series#Radeon_F...

marmaduke 6y ago
> The reason the Radeon HD 6000 is not supported for hardware accelerated encoding is simply because it did not have a video encoding ASIC to use. Doesn’t this prove the broader point that GPGPU cross platform would benefit everyone? A new codec is written.. and everyone gets to use it not just those with fixed function support.
- zamadatix 6y ago
  No, it proves fixed function hardware outperforms general purpose hardware for the task it's made for. Without the fixed function hardware the GPU is worse suited for the task than a general purpose CPU.
Abishek_Muthian 6y ago
>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