<p>The actual sending of data is the same. The PCIe bus is the same speed in both directions.</p>

<p>However when programming there is a big difference namely that when you send you can immediately start doing something else (including queuing other operations using that new data) while the actual transfer is going on. But when receiving you need to synchronize on the completion of the transfer before you can use the data that was sent.</p>

CC BY-SA 3.0
2018-01-25T12:52:34.560Z
That's not exactly accurate, though. Commands that actually send data to the API are *still* synchronous, e.g. you can immediately free the memory that you called `glBufferData` with right after calling it, since it's copied into the API then. What *is* possibly unsynchronized is the transfer of that data to the actual GPU memory. However, the same asynchronous transfer approaches can be applied for data download, too. It's just that in this case you usually have to wait for all previous operations to finish.
Christian Rau
CC BY-SA 3.0
2018-01-25T13:02:30.370Z
@ChristianRau but most of the time the data you send through glBufferData is first copied to another part of memory from which the actual transfer to the GPU will take place asynchronously.
ratchet freak
CC BY-SA 3.0
2018-01-25T13:03:44.503Z
Yeah, but you could as well do that with `glReadPixels`.
Christian Rau
CC BY-SA 3.0
2018-01-25T13:07:39.497Z
@ChristianRau no because the driver cannot know you want that data until you call glReadPixels which is the trigger to make the gpu start sending data to RAM. The glReadPixels call cannot return until the GPU is done and the data is ready to be used.
ratchet freak
CC BY-SA 3.0
2018-01-25T13:16:57.980Z
No, `glReadPixels` *will* return immediately if you tell it to copy that data into a buffer object. Then you can do other things and *then* you can retrieve the data from the buffer whenever you want.
Christian Rau
CC BY-SA 3.0
2018-01-25T13:24:04.890Z
@ChristianRau oh you were using `GL_PIXEL_PACK_BUFFER`, yeah that will let you do transfers async (though you have to assume the driver isn't dumb enough to leave that in vram)
ratchet freak
CC BY-SA 3.0
2018-01-23T12:04:46.377Z
2018-01-26T20:56:24.617Z
2018-01-26T20:56:24.617Z
ratchet freak
<p>Why sending data from gpu to cpu is slower than cpu to gpu?</p>

<p>I heard the relation is similar to network situation, in detail, the upload is slower than download. However, I could not understand the meaning.</p>

<p>In my opinion,  the sending operation should be same because the two sending buses (cpu to gpu and gpu to cpu) can be made with the same performance (I mean bendwith). </p>

CC BY-SA 3.0
2018-01-23T09:30:06.543Z
What makes you think it is necessarily slower? If you can [edit] your question to add that extra detail, you'll get better answers.
Dan Hulme
<gpu><data-structure>
Why sending data from gpu to cpu is slower than cpu to gpu?
shashack
# Why sending data from gpu to cpu is slower than cpu to gpu?

(Asked by: username_0 on 2018-01-23)

Why sending data from gpu to cpu is slower than cpu to gpu?

I heard the relation is similar to network situation, in detail, the upload is slower than download. However, I could not understand the meaning.

In my opinion, the sending operation should be same because the two sending buses (cpu to gpu and gpu to cpu) can be made with the same performance (I mean bendwith).

**Tags:** gpu, data-structure

> **Comments:**
> **username_1**: What makes you think it is necessarily slower? If you can [edit] your question to add that extra detail, you'll get better answers.  

---

## 1 answers

### Answer by username_2 on 2018-01-23. Score: 7 | Accepted answer

The actual sending of data is the same. The PCIe bus is the same speed in both directions.

However when programming there is a big difference namely that when you send you can immediately start doing something else (including queuing other operations using that new data) while the actual transfer is going on. But when receiving you need to synchronize on the completion of the transfer before you can use the data that was sent.

> **Comments:**
> **username_3**: That's not exactly accurate, though. Commands that actually send data to the API are *still* synchronous, e.g. you can immediately free the memory that you called `glBufferData` with right after calling it, since it's copied into the API then. What *is* possibly unsynchronized is the transfer of that data to the actual GPU memory. However, the same asynchronous transfer approaches can be applied for data download, too. It's just that in this case you usually have to wait for all previous operations to finish.  
> **username_2**: @username_3 but most of the time the data you send through glBufferData is first copied to another part of memory from which the actual transfer to the GPU will take place asynchronously.  
> **username_3**: Yeah, but you could as well do that with `glReadPixels`.  
> **username_2**: @username_3 no because the driver cannot know you want that data until you call glReadPixels which is the trigger to make the gpu start sending data to RAM. The glReadPixels call cannot return until the GPU is done and the data is ready to be used.  
> **username_3**: No, `glReadPixels` *will* return immediately if you tell it to copy that data into a buffer object. Then you can do other things and *then* you can retrieve the data from the buffer whenever you want.  
> **username_2**: @username_3 oh you were using `GL_PIXEL_PACK_BUFFER`, yeah that will let you do transfers async (though you have to assume the driver isn't dumb enough to leave that in vram)  

---

