I've been learning to write shaders recently. And have often seen many situations where people are sending textures or particle data in the megabytes some times with no real issues to a GPU.

But then when I read about sending data back from the GPU to the CPU - its pretty much best to avoid because its slow especially if there is a lot of data.

I landed into this problem when I was trying to implement an Fourier transform (FFT) algorithm, and then sample the result on the CPU every frame via a texture... it was just too slow sending data back to the CPU. This was for a game so performance matters.

Why don't hardware manufactures design their hardware to solve this problem?

  • Are you using a GPU compute API like CUDA or OpenCL? Graphics APIs are not designed with the expectation that shader output and other data are going to be read back from the GPU intensively. Furthermore, graphics drivers may not be optimized that sort of use-case. On the other hand, GPU compute APIs are designed specifically for getting the output of a "compute shader".
    – Romen
    Commented Sep 4, 2019 at 21:12
  • I'm my case I'm manipulating the mesh surface for water waves, but the cpu runs physics based on the mesh surface for buoyancy of objects on the mesh so they need to know the height calculations from the gpu every frame to keep in sync. Strange to me they don't design them with the expectation of data to be sent back to CPU.. games need that a fair bit.
    – WDUK
    Commented Sep 4, 2019 at 21:51
  • The problem could be that the CPU is the "bus master", and the GPU needs to request access first. That world create such an inequality in priority.
    – Mokubai
    Commented Sep 4, 2019 at 22:12
  • This question should be on Stack Overflow. Commented Sep 19, 2020 at 13:08
  • no it shouldn't @AkibAzmain it is not a programming question.
    – WDUK
    Commented Sep 19, 2020 at 20:13

1 Answer 1


Why don't hardware manufactures design their hardware to solve this problem ?

First let me preface my answer by disclosing that I'm not an expert on PCI express or the low-level implementation of GPU <-> CPU communication. I believe there may be some details on that level that bias the performance in favour of CPU to GPU.

But for the most-part, I believe the bottleneck is at the software/API level. GPUs have plenty of performance available in the GPU -> CPU direction.

Graphics APIs like OpenGL and DirectX are designed to implement a graphics pipeline on the GPU. In its simplest form, the pipeline is a one-way flow of data from the CPU to the GPU to the monitor. These APIs are designed to optimize that pipeline as much as possible so that games and other graphical applications can achieve high framerates.

Despite that, there are ways of retrieving data back from the GPU, for example in OpenGL:

Using these methods is akin to placing a traffic light somewhere along the pipeline. That is because transferring data back to the CPU memory means that data has to be locked. The rendering pipeline may need that memory for the next frame though, so copying shared data back to the CPU every frame is going to force the GPU to alternate between copying the data and processing the pipeline.

The biggest optimization that can be done to avoid that problem is to switch between two or more buffers every frame so that the GPU download does not have to block the pipeline.

I should also mention that GPU compute APIs like CUDA and OpenCL are designed to let the developer have more control over how shaders are used; They do not force you to use them in any sort of pre-made pipeline. It would be possible to generate your waves geometry in a compute shader, copy it back to RAM for physics, and then pass it back to the graphics API for rendering. You can also get compute APIs to interop with graphics APIs so the vertex data can be handed over in the GPU memory itself.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .