An update on AGP 4X and being worth squat
It ain't worth squator is it? My quick article on advanced AGP modes and Windows 2000
kicked up quite a storm of comments
and e-mail. I felt like a Florida election official sorting through the results tonight, and nope, I don't have it all sorted out just yet. (Officials from NVIDIA are demanding a recount.) I'm afraid I'll be off to Comdex before I can report anything conclusive.
I do have a heap of potentially useful input from you all, including AGP stress testing suggestions and tips on making AGP 4X mode "really" work. A couple of notes:
- Some of you were suggesting I test at very high resolutions in order to see if AGP helps. I can do that, but it sounds to me like some folks are conflating AGP bandwidth with video card fill rate. I don't believe the two things are closely related. The same command, texture, and polygon data has to pass over the AGP bus for rendering a 640x480x32 scene or a 1280x960x32 scene. I believe. But I'd love to be proven wrong.
- A few of the commenters busted out the serious technical know-how and started asking questions about the relative memory bandwidth of different subsystems inside a Pee Cee. I think you guys are on to something. Have a look at this, and see if I've got the basics right: (Note to know-it-alls: I know it's the ultimate geek temptation, but if you don't really know this stuff, don't bug the rest of us.) You'll notice that the effective memory bandwidth (on the Stream test) on my KA7-100 with 100MHz SDRAM isn't too stellar.
- Finally, this AGP 8X inteface spec document pointed out by Ryu Connor should help clarify how AGP sidebanding, fast writes, and pipelining affect the effective and peak numbers in the chart above.
I could go on, but I don't want to tip my hand entirely. And like I said, I don't have it all worked out yet. The input is much appreciated, though, and some answers (and probably more questions) are coming.