Rendering of a sidewalk

Sorry, Its not an important point, just that the sand texture looks like its at least twice as big as it should be, if you look at the size of the rocks and pebbles and stuff on the sand they are much bigger than the rocks and pebbles on the pavement, also the sand looks much blurrier than the pavement. This would be fixed by just scaling down the sand texture.

 

Only 2 or 3? That's probably a bit on the low side.

Once you are using more texel data than will fit inside the texel cache (which, in all honesty, won't be very large) the texture data transfer across the external bus will become important.

Taking your example, and assuming you have 16bpp textures, then a 512x512 texture+MIP map is ~680KB. (Turning off MIP mapping only makes things worse). I'd imagine that there might be a silicon budget for, say, somewhere between a 4kb~64kb texture cache, so you will only be able to store a small fraction of a texture at a time.

In effect, the cache really only saves re-reading data that are shared between pixels when doing the texture filtering operations. You are thus probably still going to need to read, on average, 3 texels for each pixel.

Even if you could address individual texels with 100% efficiency out of the external RAM (which you can't do anyway), that would be 48bits/texel op. If we assume a measly 2 pipes (or dual texturing) then we are up to 96 bits. That's becoming a significant proportion of your bus width.

 

OK I'm including some translucency effects as well.

As a rule-of-thumb, it's not a bad assumption (provided the developer turns on MIP mapping, grrr. Perhaps a "thump-rule" is needed after all.).

 

Well, that would depend on how AF is implemented and there isn't really a standard but, I would say, on average, "no". With AF you are using a filter with a higher number of taps per pixel and I doubt there'd be as much overlap between the used texels in adjacent pixels.