4 ms·
You shouldn’t copy the frame data to the GPU (assuming that’s literally what your code was doing). Instead create a GPU texture that’s backed by a fixed buffer
by pavlov 5y ago
You shouldn’t copy the frame data to the GPU (assuming that’s literally what your code was doing).
Instead create a GPU texture that’s backed by a fixed buffer in main memory. Decode into that buffer, unlock it, and draw using the texture. The GPU will do direct memory access over PCIe, avoiding the copy.
The CPU can’t be writing into the buffer while the GPU may be reading from it, so you can either use locks or double buffering to synchronize access.
- danachow 5y ago> Instead create a GPU texture that’s backed by a fixed buffer in main memory. Decode into that buffer, unlock it, and draw using the texture. The GPU will do direct memory access over PCIe, avoiding the copy. With a dedicated GPU with its own memory there still is usually a memory to memory copy, it just doesn’t have to involve the CPU.
- pavlov 5y agoYeah, like so many other things in the GPU world, main RAM texture storage is more of a hint to the graphics card driver — "this buffer isn't going away and won't change until I explicitly tell you otherwise". It definitely used to be that GPUs did real DMA texture reads though, at least in the early days of dedicated GPUs with fairly little local RAM. I'm thinking back to when the Mac OS X accelerated window compositor was introduced — the graphics RAM simply wouldn't have been enough to hold more than a handful of window buffers.
- zoenolan 5y agoI would build on that saying, you should look at double buffering or maybe triple buffering. Frame A is copied to the GPU. Frame B is being decoded into Frame B is copied to the GPU. Frame C is being decoded into Frame C is copied to the GPU. Frame A is being decoded into