Hacker News Reader

Comment by Temporary_31337 | Hacker News Reader

How does this compare to the naive GPU performance on an RTX GPU?

If the entire program was on the GPU, that specific part would be extremely fast.

But the rest of it is on the CPU because GPU cores aren't any good at largely serial things like video decoding. So it doesn't matter.

> GPU cores aren't any good at largely serial things like video decoding

I'm surprised to hear this, considering GPUs are often used for video encoding and decoding. For Nvidia cards, this is called NVDEC, and AMD/Intel both have corresponding features for their video cards.

That doesn't use the GPU cores. They just happen to package dedicated video hardware alongside it, but it's more similar to a CPU with a specialized DSP attached.

Any kind of decompression isn't fully parallelizable. If you've found any opportunities, that means the compression wasn't as efficient as it theoretically could be. Most codecs are merciful and eg restart the entropy coder across frames, which is why the multithreaded decoding in ffmpeg is able to work.

(But it comes with a lossless video codec called ffv1 that doesn't allow this.)

Yeah, I wrote my CS dissertation on this. It started as me writing a GPGPU video codec (for a simplified h264), and turned into me writing an explanation of why this wouldn't work. I did get somewhere with a hybrid approach (use the GPU for a first pass without intra-frame knowledge, followed by a CPU SIMD pass to refine), but it wasn't much better than a pure CPU SIMD implementation and used a lot more power.

x264 actually gets a little use out of GPGPU - it has a "lookahead" pass which does a rough estimate of encoding over the whole video, to see how complex each scene is and how likely parts of the picture are to be reused later. That can be done in CUDA, but IIRC it has to run like 100 frames ahead before the speed increase wins over the CPU<>GPU communication overhead.

NVENC/NVDEC and similar technologies use what is effectively an ASIC that happens to be integrated on the GPU. It doesn't use the general purpose GPU cores. This is the reason why the limitations on e.g. which codecs it supports are so strictly tied to the hardware generation; it's just fixed function hardware.

There's no reason you can't bundle the same kind of ASIC on a CPU too, and indeed Intel does do that with QuickSync. For video game capture/screen recording though (which is a big part of what people tend to do with NVEnc) it might be a bit more convenient for the chip to be on the GPU? I don't know, not a GPU expert.

> For video game capture/screen recording though (which is a big part of what people tend to do with NVEnc) it might be a bit more convenient for the chip to be on the GPU?

Yeah there's usually a fast path which copies the framebuffer directly to the encoder internally, so the huge uncompressed frames never have to be transferred over the PCI Express bus.

That's exactly what I was thinking of, but I didn't know for sure. Thanks for confirming.

NVENC is trash, fast trash, but trash none the less. Encode the same source file with FFMPEG at the same bitrate using NVENC and the CPU and the loss of quality with NVENC is readily visible. NVDEC is fine, but if you're encoding with the CPU, you'll lose performance moving the frames over to the CPU. Sure you can offload it all with NVDEC+NVENC, but only if your only criteria is speed, rather than quality or file size.

this type of decoding doesn't use GPU cores.

Intel has QuickSync on their CPU cores and that has reigned supreme for many years. That's not a GPU block.

The GPU is a lot slower than the CPU - per core/thread. Otherwise you would need to select different core/thread counts on both sides, or set something like a power limit in watts. When it comes to watts the process node (nanometers) will largely determine the outcome.

Reply on news.ycombinator.com