Hi Seni,

Seni (seniike@hotmail.com) on 2/24/11 wrote:
---------------------------
>Nicolas Capens (nicolas.capens@gmail.com) on 2/24/11 wrote:
>---------------------------
>>Seni (seniike@hotmail.com) on 2/22/11 wrote:
>>---------------------------
>>>>>Texels are processed in quads because it is needed to calculate mip-levels for dependent texturing.
>>>>>This of course only applies to GPUs that support dependent texturing, so anything DirectX 8+.
>>>>
>>>>That doesn't mean it's processed a quad at a time. You can have a single scalar
>>>>pipeline process each operation for a quad of pixels sequentially. So there's no
>>>>reason to assume that the IGP's samplers are really configured as a quad of samplers.
>>>
>>>You need to run all 4 pixels of the quad in lockstep so the TMU can do finite differencing between adjacent pixels.
>>>This is fundamental to the way it chooses what mip-levels to sample from.
>>
>>I know how differential mipmap LOD computation works, I implemented it myself in
>>SwiftShader (and yes that means it supports dependent texture reads). But it's incorrect
>>that this strictly demands lockstep execution. Like I said, if you have a scalar
>>execution unit you can still process quads,
>
>That's what I was saying - you still process quads.

No, you said the samplers had to be quads of samplers working in parallel: "Each sampler does a 4-texel quad at a time, so 2 of them do 8 texels per cycle."

>>simply by executing the same operation for each pixel sequentially.
>>
>>While there's no reason these days not to process the arithmetic operations of
>>a quad concurrently on four lockstepped execution units, having texure units which
>>sequentially process a sample for each pixel still makes sense.
>
>Actually, the texture lookup has a much higher latency than most of the shader
>instructions, so it's all done pipelined and not really sequential at all. But I see what you're trying to say.

I'm not "trying" to say something. Of course it's pipelined. It just takes four cycles to finish the sampling for a quad. That's how I explained it from the beginning: " You can have a single scalar pipeline process each operation for a quad of pixels sequentially."

>>>But all of this is beside the point, which is: just how much much texel fillrate does this IGP actually have?
>>>And the answer is we don't know, since the techarp link you gave has been discredited.
>>
>>An NVIDIA GT218 weighs in at 260 million transistors,
>
>Do we really care about transistor count? It doesn't correlate well with area
>or cost, or really anything except the amount of SRAM on the chip.

In the case of GPU and IGP architecture, I think it correlates closely enough. Especially considering that both NVIDIA and Intel use ~1.3 GHz clocks.

I think it's the best measure of design complexity we have, but I'm open to other suggestions if you have any.

>>can do 69 GFLOPS, and according
>>to Wikipedia has a texture fillrate of 4.712 GT/s.
>
>And an Nvidia GT218 is a terrible unbalanced low-end GPU. Dunno why you would
>bring it up as it's not a good example of anything. It's just a flat-out bad chip.
>I'm guessing you chose it specifically because it has the worst texel fillrate of anything you could find.

No, I chose it because it has a similar clock speed and similar transistor count.

And what makes you think it is terribly unbalanced? If that was the case, why wouldn't NVIDIA have done something about that? Did you think they intended not to sell these chips, by design? Heck, if I really wanted to pick a chip with low texture fillrate I would have chosen the GF110, which has less than half the TEX:ALU ratio of a GT218!

>>The HD Graphics 3000 is roughly 180 million transistors (not counting the memory
>>controller shared with the CPU cores), and can do 130 GFLOPS. So what seems most
>>likely, a texture fillrate of 5.4 GT/s, or 21.6 GT/s (half that of a GeForce GTX 570)?
>
>You're asking me to guess it? This is silly. We need to find a reliable source,
>or, better yet, to actually measure it.

It was a rethorical question. There's no reason to doubt it has any more than 5.4 GT/s of fillrate.

Here's more proof: http://www.techpowerup.com/gpuz/kfqmq/ At 400 MHz a texture fillrate of 1.4 GT/s means it has 4 samplers. This is for the Arrandale IGP, which also has 12 EUs.

>>It could still be something in between, but let's face it, that 5.4 GT/s number sounds quite believable.
>>
>>>>As I've mentioned before on this forum, the number of pixels hasn't increased
>>>>all that much and there's only so many texels you can slap on a pixel (plus the
>>>pre-z pass keeps shading to a minimum).
>>>
>>>Nope. There's no limit to how many texels you can slap on a pixel. Nor should there be.
>>
>>That's not what I meant. A developer can only apply so many *meaningful* texels
>>to a pixel. If the IGP's texture fillrate had been 21.6 GT/s, you could have more
>>TEX instructions than 4-component MAD instructions.
>
>Which is fine, since not everything has all 4 components. See the example below
>where I use 3 texture lookups and 3 3-component MADs.

Such shaders are the exception, not the rule. Like I said before, they are the reason texture fillrate is generally overdimensioned, but they're largely idle much of the time. Most shaders have a far lower TEX:ALU ratio. For instance ATI's Whiteout demo had 1:13 ratio, and that was back in 2006. This is also reflected in modern GPUs: The GF110 can do four MAD4's for every sample operation, and it's exactly the same ratio for Cayman.

Even at just 5.4 GT/s Intel's IGPs have a higher texture fillrate ratio. So once again, there's no reason to think it has an even higher fillrate.

>>Anyhow, that's still a very high number of texture operations per pixel. And I have the data to back it up. I played a bit of Left 4 Dead at 1024x768 at low detail and it averaged to 6.5 million texture operations per frame. With 5.4 GT/s that's low enough for the IGP to theoretically run it at 830 FPS. Instead, it runs it at 70 FPS when overclocked: http://www.xbitlabs.com/articles/video/display/intel-hd-graphics-2000-3000_7.html#sect4
>>And it runs at 275 FPS on my GTX 460 so it's not CPU limited.
>
>Still a low res. I take it you disabled anisotropic filtering to inflate your numbers?
>Or equivalently, counted only the base tex instructions and not the subsamples
>implied by the trilinear/aniso algorithm.

TEX:ALU ratio is resolution independent. And no, I didn't disable anisotropic filtering, but these games simply don't use anisotropic filtering at low settings.

I counted trilinear samples as one texture operation, since the IGP can do it in one clock cycle: software.intel.com/file/33239

>>This data corresponds to an average of about 8 texture operations per pixel. I
>>didn't expect much more since the walls appear to have just an albedo map and a
>>lightmap, and I was using a torch light.
>
>So what you're saying is this is an old and low-tech game and not representative of modern workloads?

Yes, Left 4 Dead isn't representative of contemporary workloads. They have a significantly lower TEX:ALU ratio.

>>A bit of overdraw probably accounts for
>>the rest. All the other games the IGP runs at a good framerate at low quality also
>>don't appear to be using lots of texture accesses.
>>
>>Still not convinced? Crysis Warhead at 1680x1050 at Performance setting uses 19
>>million texture operations per frame. That's still only 11 per pixel, while the overclocked IGP runs it at 37.5 FPS.
>
>This is decidedly more interesting. I take it you disabled aniso here too?
>Which overclocked IGP is this? Why are you overclocking it while citing the non-overclocked fillrate?

X-bit Labs uses low settings. I can only assume this means disabling anisoptric filtering. And they used an HD Graphics 3000 overclocked to 1500 MHz. I'm citing the non-overclocked fillrate because that makes my comparison more conservative. In other words, the IGP is even less texture fillrate limited than these number illustrate.

>>>Take into account 2x-3x for for trilinear & anisotropic filtering and we're down to 38-57.
>>>Figure in 2x-4x overdraw and we're down to 9-28 texels/pixel, which is not really so much. Consider:
>>>-4 shadow maps, one each for 4 lights
>>>-diffuse map
>>>-specular map
>>>-bump map
>>>-reflection cubemap
>>>That's 8 right there for a fairly basic shader.
>>>
>>>What if you want to compute the diffuse+specular term by combining multiple textures
>>>procedurally? Then instead of 1 specular + 1 diffuse, you might have 4 or 8 of each.
>>>Also, if a portion of your frame time is spent on non-texturing passes, such as
>>>generating those shadow maps in the first place, then you don't have the full 1/60th
>>>of a second to do your texturing in.
>>>So you need to increase the texel fillrate further to make up for that.
>>>Also, texture lookups are sometimes used in a shader as general table-lookup functions rather than actual textures.
>>>And sometimes it makes sense to do multiple texture lookups into each shadow map, so as to get a better shadow edge.
>>>And so on...
>>
>>You're forgetting that all of that would require lots of arithmetic instructions
>>as well.
>
>Some of it does. Some of it doesn't. Bump-mapping is alu-intensive. Shadow-map lookups not so much.
>Combining multiple textures to compose a more complex surface description can be pretty cheap.
>
>For example, in a game, the ground might be made of a dirt texture, a sand texture,
>a rock texture and so on, with per-vertex coefficients to describe a particular piece of ground.
>A particular piece might be 30% sand and 70% dirt. And you do all the lookups
>and then blend 30% of one and 70% of the other and 0% of the third.
>This is something that without shaders would have been done in 3+ separate passes.
>Here we just do a few lookups and then some weighted sums.
>And since they are weighted sums of colors, it's only a three channel MAD for each.
>Like this:
>
>Lookup temp = sand_tex[texcoords]
>MAD accum.rgb = temp * sand_coeff + accum
>Lookup temp = dirt_tex[texcoords]
>MAD accum.rgb = temp * dirt_coeff + accum
>Lookup temp = rock_tex[texcoords]
>MAD accum.rgb = temp * rock_coeff + accum
>
>You could do as many layers like this as you want although beyond a certain point it would be wasteful.
>so, this in particular uses a lot of texture lookups but not all that much alu work.

I sincerely suggest you take a look at some shaders used in actual games. You'll find tons of other instructions to perform per-pixel lighting, exp and log for gamma correction, texture coordinate transformations, lots of matrix transforms for vertex skinning, comparison instructions, some branches, etc.

Of course there are also short shaders which perform little more than one texture operation, but those are actually bottlenecked by ROP so extra samplers don't help here either.

And yes, your ground shader becomes wasteful beyond a certain number of layers. Again, there's only so many *useful* texture operations a shader can use. As shaders get longer, the TEX:ALU ratio goes down. This has been a fact for as long as shaders have existed.

So the Intel HD Graphics 3000 must have 4 samplers in total.

Cheers,

Nicolas