[JF_Aidan_Pryde]

I've read many developers cry about the need for faster AGP (8x). They say that triangles are getting bottlenecked at the AGP bus. Is this a real problem?

Every real-world (or even synthetic) tests show no more than 5% improvement with AGP bus doubling in bandwidth. AGP has been the least benchmarked bottleneck in 3D graphics, and there just seem to be no problem with it in terms of bandwidth.

What is the main possible bottlenecks for the AGP?

So far I've thought of

1) Huge triangle trafic
2) Large textures over flowing the onboard RAM
3) ?

Thoughts?

[RussSchultz]

Just recently, Ben6 (I think) was complaining that his Radeon suddenly got a vastly reduced 3dmark score. The end result was his motherboard/video card suddenly decided that AGP2x was as good as it was going to get.

So it obviously does something. (Though, I do remember the idiotic wars about AGP being useless when AGP2x came out)

[rubank]

If it is of any interest:

I ran Comanche4 benchmark in AGP2x and 4x resp.
Triangles/sec was up some 17% at AGP4x, (while the benchmark score was up ~14%). This at 10x7x32.

This with an old Radeon32DDR, on a KT266A m/b with an Athlon XP@ 1523 Mhz.

[Hyp-X]

Originally Posted by JF_Aidan_Pryde

I've read many developers cry about the need for faster AGP (8x). They say that triangles are getting bottlenecked at the AGP bus. Is this a real problem?

Every real-world (or even synthetic) tests show no more than 5% improvement with AGP bus doubling in bandwidth. AGP has been the least benchmarked bottleneck in 3D graphics, and there just seem to be no problem with it in terms of bandwidth.

What is the main possible bottlenecks for the AGP?

So far I've thought of

1) Huge triangle trafic
2) Large textures over flowing the onboard RAM
3) ?

Thoughts?

When there are large textures overflowing - a fast AGP is never fast enough.
There is two solutions available when the video ram is not enough to store all textures:
a.) texture management
b.) texturing from AGP memory

a.) With texture management you load all your textures in system memory, and start with a clean video memory. (Apart from the framebuffer of course.)
When rendering a scene when encountering a texture which is not in the video memory, space is allocated for it in the vidmem, and the texture is copied there and the drawing call is executed with the vidmem version of the texture.
When there is not enough space, the last recently used texture is discarded (freed) from vidmem.

b.) The other method just starts loading textures needed for the level into vidmem until there is space. When there's no more space the remaining textures is loaded into AGP memory. (It's a good idea to load textures in some priority order so the highest priority textures end up in vidmem.)
Drawing calls uses the texture from vidmem or AGP mem depending where it was placed.

Both method have their advantages and disadvantages, and are affected by AGP speed differently.
Both methods are available in D3D, and it's the developers choice.
In OGL "texture management" is the default choice, I don't know if a developer can chose method B.

Both methods run smoothly if all the textures in a level can be fit in vidmem. (Would be the shame if this wasn't the case.)
In this case AGP speed is not interesing.

When there are more textures:
a.) It runs smoothly while you are in one area where all textures can fit in the vidmem. When you move from one area to other you might experience a slight pause or lag, when the new texture is uploaded.
With faster AGP the lag will be smaller, but it will always be there.

If you go to an area where there are more textures than vidmem, the FPS goes down radically. This is where the AGP speed counts the most, but it'll never be good with any speed AGP, partly because this method does not use the bandwidth efficiently.

b.) You will experience slow-downs when you are in an area where the textures in AGP memory regardless how much textures are used in that area. It might be so that a complex room with textures in vidmem is faster than a simple small room with AGP memory textures.

This method also limits the maximum amount of textures to the sum of vidmem + AGP memory which is unpredictable since not all cards/drivers support AGP texturing in the first place. Also there's an option to disable it in many drivers/tweekers which has been used to increase stability in many configurations -> some users will disable it by default.

None of the two is really efficient:
a.) It uploads the whole texture / all detail levels, regardless of which part of it will be needed. (Might be non if the surface uses it is occluded!).

b.) It does not cache (except on 3dlabs cards) the texture so if it is used on multiple surfaces it'll be read multiple times.

... to be continued.

[Joe DeFuria]

(Though, I do remember the idiotic wars about AGP being useless when AGP2x came out)

Actually, those wars were not really "idiodic." They were mostly about the "usefulness" of AGP texturing for games IIRC. I don't think anyone really argued against having more bandwidth in general. On the other hand, I don't think that anyone today could care less if a card supports AGP texturing directly from system memory or not.

EDIT: Ahhh...I see Hyp-X is laying a good foundation about what those "idiodic" wars were all about.

[Hyp-X]

With texturing the developers of a games try not to use more textures than can be fit in vidmem of their high-end target, and provide a "texture detail" setting for their low/mid-end target and the problem is considered solved.

One thing that I didn't wrote about is dynamic textures. They are present in the original Unreal engine, and what are to be avoided at all cost. They cause all kinds of bottleneck causing the engine to not scale well with the hardware...

Geometry is similar to textures except that dynamic geometry is rarely avoidable.

For static geometry everything holds that I wrote about textures.

Dynamic geometry on the other hand is usually placed in AGP memory and is used from there regardless of the management method used for static one.

Reasons for using dynamic geometry: using software T&L (duh), using an effect that the card cannot do in hardware (no VS, etc) or bad programming...

I can see only one valid point in the above list

Example: character blending (tweening) on a card (like GF2) that cannot do it in hardware.
Since the geometry data is read trough the AGP bus it is vital to know how the GPU caches work or it will read the vertices multiple times (-> bad).
In this example with AGP 1x the bottleneck is clearly the AGP. With AGP 2x it depends on the actual machine. With AGP 4x the bottleneck is usually - the memory bus of the CPU...

On other hand this can be all done with the GPU if it supports Vertex Shaders or it supports Tweening (Radeon). It allows putting the source geometry data in static buffers, benefiting from it's advantages.

Some of the reasons that some applications is slow - is no doubt caused by the developers failing to understand how the hardware works, what should be done on the CPU, what on the GPU, etc.
(And I can't claim to know all, in fact I just starting to realize how much more should I learn about how 3D hardware / drivers work.)

[Nagorak]

If you think about it, the increase in AGP bandwidth isn't really making a difference, relatively speaking. I mean, think about it, originally with AGP 1.0 spec we had cards with 8-16 MBs of memory. Then we had AGP 2x with 32 MB cards. Then 4x and we were getting into 64 MB (and even 128 MB). Now 128 MB cards are the norm.

Presumably video memory has been increasing because texture detail (and size) have been increasing. So now we have cards that can transfer across the AGP bus 8 times as fast, but they also have 8 times as much memory and presumably textures are now also 8 times as large. In other words AGP 8x isn't really an "improvement" in any way, it's basically just to keep up with the larger texture requirements of the present and the future.

[OpenGL guy]

Originally Posted by Nagorak

Presumably video memory has been increasing because texture detail (and size) have been increasing.

I'd say video memory has been increasing because performance is getting higher so people want higher resolutions. Also, features like AA can take up more memory as well.

Another reason to use more memory is because of local vertex buffers. "Code Creatures", for example, loads a bunch (like more than 64 megs worth) of 4 meg vertex buffers.

In other words AGP 8x isn't really an "improvement" in any way, it's basically just to keep up with the larger texture requirements of the present and the future.

You don't need faster AGP for texturing. If your textures aren't in local video memory, you are going to have performance troubles because of the huge difference in available bandwidth between AGP and local memory. The faster AGP protocols are being used more for vertex and command data. Texture data is generally loaded all at once at the start of a scene (i.e. beginning of a level in a game) so that they won't affect performance later.

[Doomtrooper]

I've got a old Pcgamer around here somewhere where they interviewed Intel and how AGP was going to lower costs of video cards due to the the AGP bus, they specifically stated there will be no more need for 16 meg cards and in the future video cards will be shipping with 1 meg of onboard video memory

I remember laughing back then and still laughing...