R4x0 Quad-Level Texture Samplers (?)

[Luminescent]

Does the R4x0 architecture offer a pool of texture samplers arbitrarily available at the quad level (to any pixel pipeline within a quad) or is each texture sampler limited to a single pipeline element within a quad? I believe that in NV4x and G7x, the samplers run independently, at the quad level, although I'm not sure.

 

[Xmas]

Does the R4x0 architecture offer a pool of texture samplers arbitrarily available at the quad level (to any pixel pipeline within a quad) or is each texture sampler limited to a single pipeline element within a quad? I believe that in NV4x and G7x, the samplers run independently, at the quad level, although I'm not sure.

There are no independent pixel pipelines, it's just quad pipelines really. So every pixel of a quad is doing the same thing, just with different values.
Therefore, it makes no sense to have samplers arbitrarily available to pixel pipelines.

 

[arjan de lumens]

AFAIK, in order to properly determine mipmap levels and anisotropy to use for a give texture sample, it is common to measure the differences between the texture coordinates within a quad and then calculate appropriate levels from those differences.

It might make sense to support separate per-pixel samplers for the PS3.0 instructions 'texldl' and 'texldd', but allowing the pixels in a quad to execute out of lockstep is likely to add a rather substantial amount of extra hardware complexity.

 

[sireric]

All current ATI HW executes at the quad level in SIMD fashion for texture operations. This is partially due to the fact that quads are required for texture computations (as Arjan de lumens state), as well as due to cache coherence benefits.

As far as I know, all other mainstream HW vendors do exactly the same.

(NB: The only possible exception is for special instructions that force different LOD bias per pixel)