AGP Texture Download Problem Revealed

EconolineCrush writes "The latest high-end graphics cards are capable of rendering games at 1600x1200 in 32-bit color at jaw-dropping frame rates, but that might be all they're good for. For all their gaming prowess, all of these cards have horrific AGP download speeds that realize only 1/100th of their theoretical peak. This article lays it all out, testing video cards from ATI, Matrox, and NVIDIA, and clearly illustrates just how bad the problem is. While these cards have no problems rendering images to your screen, you're out of luck if you want to capture those images with any kind of reasonable frame rate via the AGP bus."

Comments

Re:Hmm.

[FyRE666]

Maybe you should have read the article? The point is that the slow transfer rate from the card TO the PC's RAM means that capturing video (or recording a gaming session for playback later) is severely hampered.

To be honest though, most people buy a GF4 to play games, not capture video.

Imagine That

[mosch]

Wow, what a surprise. Video cards being built on ultra-thin margins are only being designed for the use that 99.99% of the population wants to use them for. You'd think with their huge 4% and 5% profits they'd add in lots of features that only a very few people want, just in case!

In summary, who the fuck cares?

Re:Imagine That

[epine]

This is exactly the attitude that creates endless headaches mapping good concepts onto workable implementations, and results in systems becoming so convoluted by the time they work properly they are nearly impossible to maintain.

The principle of least surprise dictates that random orders of magnitude should not be sacrificed in your fundamental primitives.

It seems to me that if I spend $300 on my CPU and $600 on my GPU that I might want to be able fetch back what the GPU creates. What kind of idiot puts their most powerful processor at the end of a one way street?

There are endless reasons that could come up why this feature might need to be exploited. Just because you can't come up with them doesn't mean they don't exist. You are talking about 99.9 percent of your own creativity, which I assure you is a far sight less that the sum total of the creativity out there looking for cool new things to do.

It does make sense to consider cost/benefit here. The first observation here is that we are talking about a baseline primitive (texture returned to system memory), and that we are looking to recover a rough factor of ten, not a rough factor of 10 percent.

In the video card industry, things are designed to hit the 90 percent point. These days the GPU industry rivals the CPU industry in dollar value. I simply can't believe the graphics card companies can't afford to have someone sit down and crank this up to 50% bus utilization. I suspect they could do this without even scratching their head.

I've had to use many primitives over the years designed by this guy or his second cousin. If he only knew how much of the pain he experiences as a computer user is the result of good people bending over backwards to deal with unsuspected, arbitrary constraints when they could have been polishing the product interface instead. But some people have no imagination for these things.

It's not the cards

[tmark]

all of these cards have horrific AGP download speeds that realize only 1/100th of their theoretical peak...you're out of luck if you want to capture those images with any kind of reasonable frame rate via the AGP bus."

As the quoted article clearly indicates, the problem lies with the drivers and not with the cards, the latter which the original poster intimates.

And the underlying reason is immediately understandable: after years of AGP cards and years of noone really complaining raising this issue - (except, now, developers of video-editing software who could benefit) - it seems clear that there isn't much demand for this kind of performance. In the (near ?) future there might be, but why should these companies spend money working on driver performance in areas like this when really customers only care about how well Quake will run ?

When people are willing to pay for these features is when companies will pay to build the requisite drivers. And that is how it should be.

Might this be intentional?

[seldolivaw]

I know nothing about anything, obviously, but I can see that game designers might think it nice to be able to send stuff to your screen but for you to be unable to send it to storage somewhere.

This *is meant to be* a dumb question. Mod me down if I'm wrong; it's only Karma.

Re:Hmm.

[13Echo]

I wouldn't use one of these cards to capture video though. I can't see why most people would, actually. The Matrox cards might be an exception. Quadro is a CAD/CAM card. These are just consumer grade cards. They buffer and write video directly to the hard disk. Real video editing hardware works differently, but even they often have several gigs of onboard RAM.

So really, I guess that I meant to say that I fail to see the relevance of the article. It is kinda of silly, actually, to even want to record real-time game footage with this hardware. Just pipe the video output to a real capture card on another machine. Problem solved.

Is it me, or is the author smoking crack?

[JackAsh]

A couple of salient points come to mind when reading this article:

1) Recording games/presentations/etc. The reason why we don't do it is because if the system was capable of generating it real time in the first place, it's far less space intensive to record the parameters of the animation than the output. i.e. It's cheaper to say "Daemia fires rocket at these coordinates" than record an MPEG of said rocket shot. AND, as hardware gets better, your recording does too.

Which leads me to point 2:

2) Since it's cheaper to capture realtime animation by capturing parameters, the only use of the capture function would be NON-realtime applications - i.e. getting your Geforce5TiUltraPro to render an extremely complex scene with incredible realism at 1 fps. That's not a typo. If we have 10MB/s back-into-the-PC bandwidth and each super high resolution shot takes 10MB on average, we have a wonderful solution working at 1 fps. Spend the fill rates on 600 passes for each pixel or something like that. Imagine the quality of the scenes! Capture the damn things and be glad you're not rendering at 1 frame per hour like they were 5 years ago.

Repeat after me - if you're rendering for posterity you don't need real time... That'll come eventually.

-JackAsh

Do the sums

[NigelJohnstone]

When you record video it is normally compressed by hardware or a DSP. They are compressed for a damn good reason.

Uncompressed, say just 1600x1200x24bit is about 6Mb per frame. At say 70 frames/sec is about 420Mb a second to store to disk.

So what exactly are you going to do with that much data? If you had 512Mb of ram you could hold 1 seconds worth.
Forget a hard disk, even a 3 disk raid doesn't have that sustained IO rate.

Perhaps...

[ColGraff]

"What kind of idiot puts their most powerful processor at the end of a one way street?"

Maybe they're the kind of idiots who know most people just want the best possible OUTPUT for gaming possible, and so don't want to add any overhead in card performance - or even additional design time - that isn't related to gaming performance. You know, the idiots who make cards that get award after award from gaming companies, then write near-perfect drivers, port those drivers to linux, and let you overclock the card to your heart's content. Those sort of idiots. My, they're idiotic.

Nobody says, "buy a geforce 4 ti, make the next toy story." No, it's advertised as a gaming card, and that's what its designed to do. If you want to do high-end video rendering things, perhaps a gaming card isn't the best choice.

Re:128 bit colour?

[Viking Coder]

First, Matrox and 3dLabs are both shipping products that do 10r-10g-10b-2alpha color.

Second, the poster wants to do more than "make due". You can also make due with 16 colors. And no, 256 levels is not enough, if you're compositing many images together, or if your data has a high dynamic range (which would require more gamma range than 256 levels are capable of providing, without serious banding.)

Third, pot. Kettle. Black.

You're supposed to render to an offscreen buffer

[Animats]

If you want the rendered image back in main memory, render it into an offscreen buffer, or "pbuffer" in the OpenGL world. That's the standard approach, and it's designed to be fast, unlike reading back the screen buffer. Here's an NVidia tutorial for developers on how to do it. Not only is it faster, you don't have to worry about what the user is doing with overlapping windows or seeing the cursor in the picture.

OpenGL supports reading back the screen buffer mostly so that the OpenGL validation suite can check the rendering accuracy. For that, it doesn't have to be efficient. And if you read back in some format other than the actual structure of the framebuffer, every pixel gets converted in software and performance will be awful.

This article reads like it was written by an overclocker, not a graphics developer.