   Speed of data transfer between GPU and CPU
  Hello, guys. I'm doing a project that requires reading data from GPU to the CPU, process it on the CPU, and send it back to the GPU. But I'm having some performance issues.Currently, I'm doing the transfer using pixel buffer objects that read from GPU frame buffers (with the glReadPixels instruction) and I'm writting the data back to the GPU using pixel buffers that write into textures (with the glTexSubImage instruction).I'm aware of the importance to use the native texture formats for fast reading and writting and I'm taking that into account, but the transfers still have a big (although not critical) impact on performance. Since I'm being careful with the data formats I use, I suspect the performance drop isn't caused by any data conversion perfomed by the driver. I also tried changing the data formats to other combinations (some of them very simple) and the performance drop appears to scale linearly with the size of the transfered data, which makes me think that the problem is the hardware's data transfer speed between the GPU and CPU.The amount of data that is transfered per frame from the GPU to the CPU is 5MB, and the data transfered from the CPU back to the GPU is 13MB, which totals about 18MB of transfered data per frame. For 20 FPS, the transfered data is 360MB per second, is that too much for the hardware to handle?My graphics hardware is an NVIDIA GTX260M running on a Asus G72 laptop.Thanks in advance.   
  Well the spec for PCIE 2.0 says that a 16 lane connection can transfer 16GByte/s, so its unlikely that the wires themselves are your limiting factor.What kind of performance issues are you having? Are you getting 5 fps or one frame per minute?   ;  The probablem is usually not the bandwidth, but the synchronization.if your cpu wants to access the data that your GPU generated, it will stall/wait/idle till it can access it, once the GPU is done, it will stall/wait/idle till your cpu processed it all and submitted it back for further processing (even if just showing it on screen).A nice optimization is to doublebuffer, while your cpu is processing the current buffer, the gpu could already work on the next one and once that is done transfer it back to cpu and use the last one the cpu finished.400mb/s shouldn't be a problem, I've transfered far more than that.   ;  I made a simple test where I render the desired data to a frame buffer and then extract it using PBOs with the glReadPixels, but I don't access the PBO's contents afterwards to avoid any syncronization. These are the results:just data rendering: 550 FPSdata rendering + reading to PBO: 142 FPSAs you can see, there was a considerable performance drop just by performing the reading from the framebuffer.By the way, the frame buffer is composed by 3 color attachments in the form of textures with the GL_RGBA32F format, and the reading from it is issued this way for each color attachment:glReadPixels(0, 0, width, height, GL_RGBA, GL_FLOAT, BUFFER_OFFSET(0));Do you see anything here that could cause a driver data convertion or any other kind of performance drop?   ;  > data rendering + reading to PBO: 142 FPSHow many pixels are you reading back (what is "width" and "height"?). At 142FPS, 18MB/frame is about 2.5GB/s.  This is about half PCIE 2.0 16-lane performance.  You may want to verify that your PCIE port is not 8 lanes (more common on laptops). If it is 16x, then it may be serialization caused by synchronization as Krypt0n suggested.   ;  When you render a frame all you're doing is writing commands to a buffer. To render another frame all you have to do is write more commands. To render another frame, yet more commands. Eventually, the GPU command buffer will fill up and the driver will flush it and the GPU will actually start to render those frames. However, from your POV you just rendered a whole bunch of frames in no time at all.As soon as you decide to read back a frame the driver has to flush the command buffer, the GPU has to render the frame, and then you'll have something to actually read back.If you want a more accurate measurement try sticking a glFinish() every frame in the rendering only test and you should see your frame rate drop from 550. That should at least factor in the cost of flushing every frame and get you closer to comparing the actual cost of moving your data.   