CPU to GPU data transfer speed

It's pretty fast. How large?
Try to avoid sending too much data the same frame you're gonna use it, but a few MB shouldn't be a problem.
Ofcourse there's a lot more too it and it depends on exactly how you use it.

Similar to memcpy, except maybe doubled due to driver overheads.
DDR2 RAM is ~3GB/s.
DDR3 RAM is ~6GB/s.
PCIe 8x bus is ~2GB/s.
PCIe 16x bus is ~4GB/s.

Thank you guys, it's a positive answer which I wished, but...


Why does this documentation say something that looks contrary: http://www.opengl.org/wiki/Performance#CPU_and_Bus_limits

Bus bandwidth: There is a finite limit to the rate at which data can be sent from the CPU to the graphics card. If you require too much data to describe what you have to draw - then you may be unable to keep the graphics card busy simply because you can't get it the data it needs.[/quote]

That information is correct -- if you saturate the bus, you'll cause stalling.
With a PCI 16x bus at 60 FPS, that's a theoretical maximum of ~68MB per frame total.
For an old AGP 4x bus at 60 FPS, that's a theoretical maximum of ~18MB per frame.

N.B. regular system RAM is also pretty slow -- the theoretical maximum for DDR2 at 60FPS is only ~53MB per frame!
Memory in general is usually a bottleneck, so you should reduce all unnecessary memory transfers, not just GPU memory transfers.

What kind of data are you planning on copying around every frame?

Transfer rates don't tell the full story here. Depending on the type of object you're transferring data to, and whether or not the GPU is currently using that object for drawing with, you'll also need to deal with resource contention.

As I indicated, this occurs when you try to update an object from CPU-side, but the GPU is currently using it for drawing. When this happens the GPU must flush all pending drawing commands before the update can proceed, as otherwise a pending drawing command using that object may (will) have invalid data. This is quite an expensive operation as it breaks CPU/GPU parallelism.