PCI-E 2.0 vs 1.0 impact on performance?

DarkRage

Newcomer
I have unsuccessfully tried to find any related benchmark to this issue: is the PCI-E 2.0 support from the new chipsets worthy to take into account or there is no significant performance difference between PSI-E 1.0 and 2.0. Because we know about the double bandwidth, but not the real impact it has on gaming. Someone should test some games with 8800GT with both PCI-E 1.0 and 2.0 motherboards, using details and resolutions which wouldn’t fit into the graphic memory, stressing the PCI-E bus. It would be even more interesting with one of the non-seen 256 MB 8800GT, as it would be quite easy to saturate the bus. We could extract some expectations for when games ask for 1 GB of memory for graphics.

Maybe someone could give any light on it? I don’t expect big changes, but I have no data to back it, and I will build a new computer in the next days, so this information would be helpful helping to choose the chipset.

Thank you
 
There will be zero performance difference for single card solutions. When you start talking about >2 cards there *might* be a performance difference.
 
I think you meant >1 cards... ;) But yeah, unless you're doing a lot of data-shuffling between video ram and system ram, you likely will not see any improvement until you get to dual cards (or more)

As a parallel, look for SLI benchmarks where systems were doing 4x / 8x versus 8x / 8x and see the difference. There IS a difference for SLI rigs when both cards can get more bandwidth, but it really depends on the game too.
 
Aye about the only place you'll see noticeable differences will be in software SLI/Crossfire where a physical bridge between cards isn't used.

Regards,
SB
 
I think you meant >1 cards... ;) But yeah, unless you're doing a lot of data-shuffling between video ram and system ram, you likely will not see any improvement until you get to dual cards (or more)

As a parallel, look for SLI benchmarks where systems were doing 4x / 8x versus 8x / 8x and see the difference. There IS a difference for SLI rigs when both cards can get more bandwidth, but it really depends on the game too.

I think even 2 cards are fine with current PCI-e 1.x implementations (as long as we're not talking anx16/x4 configuration).
 
yeah as mentioned previously there's no performance difference at all. I'm not really sure why PCI-E 2.0 was even introduced as it serves no real purpose. AGP 8x would still be perfectly fine for any graphics accelerator.
 
It serves no real purpose NOW, but in the future it might.

AFAICS, AGP is no go when it comes to high-def video playback and acceleration. I'm not sure if thats a limit of the CPUs or the bus or the typical GPUs placed on AGP.
 
It serves no real purpose NOW, but in the future it might.

AFAICS, AGP is no go when it comes to high-def video playback and acceleration. I'm not sure if thats a limit of the CPUs or the bus or the typical GPUs placed on AGP.

When it comes to video, bus bandwidth is never the bottleneck, except for AGP 1x.

Look at it this way: the worst possible case would be when the GPU has no hardware support at all. For a 16x12 resolution @60Hz, that would require a bandwidth of 460MB/s, which would work out borderline ok for AGP 2x (which has 533MB/s).

As soon as you start moving processing to the GPU, the required bandwidth would go down.
 
Both BluRay and HD-DVD HighDef video is 1080p -- 1920x1200 @ 60Hz. The bandwidth requirements may indeed be higher, depending on compression level. Also, you're assuming all of the processing can be done on the GPU and none of the data has to be read back to the CPU for additional processing. As soon as that's the case, the read-back bandwidth of any speed AGP kills performance.

Does anyone know for certain if/what level of processing is available for HighDef video on AGP cards?
 
1920*1080 & only 60i or 30p is my understanding.

But yeah, PCIE2.0 is probably only really going to help with load times &/or multicard setups.
 
When it comes to video, bus bandwidth is never the bottleneck, except for AGP 1x.

Look at it this way: the worst possible case would be when the GPU has no hardware support at all. For a 16x12 resolution @60Hz, that would require a bandwidth of 460MB/s, which would work out borderline ok for AGP 2x (which has 533MB/s).

As soon as you start moving processing to the GPU, the required bandwidth would go down.

Really? I beg to differ, tests show that for example 8800-series of cards have huge impacts on performance when you take out few PCI Express lanes
(yes, i know it's toms, but iirc it's not the only place they tested it at )
 
We should also consider that its not always the case that the data for a particular application, run particular resolutions and settings will reside nicely within the local framebuffer of a graphics card; I, for one, wouldn't want to be using AGP2X bandwidths with modern titles.
 
We should also consider that its not always the case that the data for a particular application, run particular resolutions and settings will reside nicely within the local framebuffer of a graphics card; I, for one, wouldn't want to be using AGP2X bandwidths with modern titles.

No, and I sure wouldn't want to be running modern titles on PCIex16 buses from 16/32mb frame-buffer 3d cards, either...;) There are obvious reasons why the frame buffers on modern PCIex16 3d cards are as large as 768mbs, 512mbs, and in some extreme single-gpu cases, a gigabyte (which to me seems a waste but that's beside the point--a gig of dedicated ram onboard a dual-gpu pcb, however, would be both useful and cool, imo, as it would be 2x512mb.) Running in tandem with this is the fact that the better crossfire and sli rigs available depend on custom bus interconnects between the cards as opposed to using the PCIex16 bus exclusively. For many 3d-related things, even PCIex16 is far too slow and still suffers from bus contention among motherboard devices. People often forget that the rate of development, improvement and deployment for discrete 3d-card local graphics buses far exceeds the rate of general computer graphics bus deployment. IE, people fixate on the cpu's graphics bus when the real performance and rendering story is found in discrete 3d-card development.

I will say, though, that I have always thought general bus advancements like PCIex16 were of critical importance to integrated graphics deployment using shared memory for situations in which high-resolutions and maximum frame rates for 3d gaming are not required or desired.
 
Really? I beg to differ, tests show that for example 8800-series of cards have huge impacts on performance when you take out few PCI Express lanes
(yes, i know it's toms, but iirc it's not the only place they tested it at )

I was answering specifically BRiT's remark about video playback. Not 3D graphics. ;)
 
Both BluRay and HD-DVD HighDef video is 1080p -- 1920x1200 @ 60Hz. The bandwidth requirements may indeed be higher, depending on compression level. Also, you're assuming all of the processing can be done on the GPU and none of the data has to be read back to the CPU for additional processing. As soon as that's the case, the read-back bandwidth of any speed AGP kills performance.

The whole idea is that the CPU will not read back data once it has entered the GPU memory.

When you look at the different stages of the video decoding pipeline, hardware support makes it way from the last processing stages to the first for this very reason.
 
Really? I beg to differ, tests show that for example 8800-series of cards have huge impacts on performance when you take out few PCI Express lanes
(yes, i know it's toms, but iirc it's not the only place they tested it at )

Well, even though it's THG, let's consider a moment that it might be true. What it *maybe* suggests is that nV driver used in the test is making a particular kind of use of the PCIex16 bus that makes the 8800-series product more dependent on the system bus than on the local graphics card bus for certain crucial things relative to 8800 performance. That in turn would bring up the question as to how nV is using all of those hundreds of megabytes of onboard local ram that come standard on the 8800-series cards. If what THG says is true is actually correct--and I don't know that it is--then it would appear the nV drivers are using caching routines for their 8800-series cards that are at least as dependent on system ram as they are on local ram--which would explain the slowdown--but not to my satisfaction, really. ...;)

Without knowing what that particular motherboard actually does when "reducing" PCIe lanes downward from what the nV product expects, it would be difficult to say whether such reported slowdowns were the result of the motherboard condition settings for "reduced" PCIe lanes, or whether the slowdown was the result of an overly cpu-dependent gpu driver approach.

Then again, it's THG, so nothing of the sort might actually be the case...;) As I mentioned earlier, gpu IHVs don't put huge amounts of onboard ram on their discrete 3d cards for kicks. They do it because their discrete 3d products can render much faster out of their local ram buses than by having to revert to rendering across the system bus from system ram. Just compare the bandwidth of the local ram bus on 8800-series products with the bandwidth of the general PCIex16 bus with all lanes turned on, and you can see what I'm talking about. The local 3d-card ram bus is way, way faster.
 
Both BluRay and HD-DVD HighDef video is 1080p -- 1920x1200 @ 60Hz. The bandwidth requirements may indeed be higher, depending on compression level. Also, you're assuming all of the processing can be done on the GPU and none of the data has to be read back to the CPU for additional processing. As soon as that's the case, the read-back bandwidth of any speed AGP kills performance.

Does anyone know for certain if/what level of processing is available for HighDef video on AGP cards?

Is the AGP bus not bi-directional? I guess that would pose some problems for decoding HD content... Anybody know what the the read-back bandwidth is for each of the different AGP standards?
 
Is the AGP bus not bi-directional? I guess that would pose some problems for decoding HD content... Anybody know what the the read-back bandwidth is for each of the different AGP standards?
IIRC, readback is the same (theoretically) as transfers to the card. The problem is that it's a single bidirectional bus--when you want to read back from the card, you can't be sending anything to it. So, there are huge penalties in performance for doing the swap. PCIe is actually two unidirectional buses and doesn't have this problem.
 
The only article that I could find right now is from TechReport. It's very dated. At that time, it seems to be rather slow readback speeds. Significantly lower than the 533 MB/s theoretical number for AGP 2x.

texdownload.gif

As you can see, pretty much every card we tested, regardless of chipset or motherboard, turned in an abysmal performance. The benchmark's 720x480 32-bit test images, which are about 1.3MB each, would only download at about 8 frames per second in most case.
 
Back
Top