JF_Aidan_Pryde said:
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.
