AGP and PCI-E
Author
quick quetion for those hardware gurus: where as if you read over the AGP bus you get a stall becuase the bus cannot do reads and wrtes at the same time, is that the case for PCI-express? if not, lots of methods are much easier to implement if you "know" you are going to write for PCI-xpress (namely lots oc image based occulsion stuff possible), glReadPixels, ect....
Best Regards
The reason that reading back data is slow isn't always the bus performance.
When using glReadPixels etc the problem is often that the data read hasn't been written yet.
In DirectX (and I assume in OpenGL) the drivers are allowed to buffer up to 3 frames, what this means is that when the CPU says render, the GPU won't finish until 3 frames later. So a read from GPU can stall up to 3 frames. This is what make GPU reads so "slow".
Edit:
If you're using a scheme like this:
Frame 0
* Render to texture 0
Frame 1
* Render to texture 1
Frame 2
* Render to texture 2
Frame 3
* Read and process data from texture 0 (GPU=>CPU)
* Render to texture 0
Frame 4
* Read and process data from texture 1 (GPU=>CPU)
* Render to texture 1
and so on, this stall could be hidden and then we're nudging at the bus transfer limits again.
When using glReadPixels etc the problem is often that the data read hasn't been written yet.
In DirectX (and I assume in OpenGL) the drivers are allowed to buffer up to 3 frames, what this means is that when the CPU says render, the GPU won't finish until 3 frames later. So a read from GPU can stall up to 3 frames. This is what make GPU reads so "slow".
Edit:
If you're using a scheme like this:
Frame 0
* Render to texture 0
Frame 1
* Render to texture 1
Frame 2
* Render to texture 2
Frame 3
* Read and process data from texture 0 (GPU=>CPU)
* Render to texture 0
Frame 4
* Read and process data from texture 1 (GPU=>CPU)
* Render to texture 1
and so on, this stall could be hidden and then we're nudging at the bus transfer limits again.
hi,
don't really answer your question, but the main difference between PCI-E and AGP is that you have an up/down bandwidth that you can parameter as you want. Don't know if i'm clear : AGP, say you have X in upload to the card and Y download from the card, it's fixed, and you can't change it. And the download from the card is really slow compared to upload. On PCI-E, you have X bandwidth for upload AND download and you can give download more bandwidth than upload if you want.
I don't remember where I heard about that, maybe I misunderstood (me and my english ... ^^')
.:: Paic Citron ::.
don't really answer your question, but the main difference between PCI-E and AGP is that you have an up/down bandwidth that you can parameter as you want. Don't know if i'm clear : AGP, say you have X in upload to the card and Y download from the card, it's fixed, and you can't change it. And the download from the card is really slow compared to upload. On PCI-E, you have X bandwidth for upload AND download and you can give download more bandwidth than upload if you want.
I don't remember where I heard about that, maybe I misunderstood (me and my english ... ^^')
.:: Paic Citron ::.
From what I've read, PCI-E is dual-piped, so you can do simultaneous up/down. No idea whether this will speed up glReadPixels, etc, but yeah it should surely (theoretically) open up a lot of possibilities.
In fact, it seems like between PCI-e, and the even more ridiculous memory-to-video card (-and-back) bandwidths on next-gen consoles, the whole mentality of "Send it to video once, leave it there, don't read anything back" is going the way of the horse-drawn buggy. It'll obviously take longer for PCs because of issues with widespread adoption, but it's definitely the future. Same thing with vertices being generated 'on-the-fly'.
Most people thought that the role of video cards would grow as video processing power grew and bandwidth stayed small... they'd have to take on extra burden with extra complexity. But the opposite is happening-- multi-core CPUs with SMP and very high memory bandwidth mean that spatial partitioning, occlusion, geometry generation can all happen "for free" in a thread in parallel with the game logic and the video will just draw the triangles it gets sent.
In fact, it seems like between PCI-e, and the even more ridiculous memory-to-video card (-and-back) bandwidths on next-gen consoles, the whole mentality of "Send it to video once, leave it there, don't read anything back" is going the way of the horse-drawn buggy. It'll obviously take longer for PCs because of issues with widespread adoption, but it's definitely the future. Same thing with vertices being generated 'on-the-fly'.
Most people thought that the role of video cards would grow as video processing power grew and bandwidth stayed small... they'd have to take on extra burden with extra complexity. But the opposite is happening-- multi-core CPUs with SMP and very high memory bandwidth mean that spatial partitioning, occlusion, geometry generation can all happen "for free" in a thread in parallel with the game logic and the video will just draw the triangles it gets sent.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
