Hi Gabriele,

Gabriele Svelto (gabriele.svelto@gmail.com) on 2/4/11 wrote:
---------------------------
>Let's start with compressed textures. You claimed they are "pointless" because
>they do not save much bandwidth, provided simulated data that happened to be wrong
>(see DK remark)...

It has not yet been proven wrong. For it to be wrong texturing has to take the majority of bandwidth and there has to be very little or no bandwidth headroom. Simply telling it is wrong doesn't make it wrong.

I've determined that Crysis at High detail and 1680x1050 resolution performs 21 million compressed texture sampling operations per frame. Assuming no magnification and no texture reuse, this comes down to 21 MB (in reality it will be less because there is some magnification and lots of reuse). At 60 FPS, that's 1.3 GB/s. So when using uncompressed textures instead, you need 4 GB/s of extra bandwidth.

Sandy Bridge has a bandwidth of 21.3 GB/s. So using uncompressed textures would make it 20% slower, right?

Wrong! There's no way Sandy Bridge's IGP will achieve 60 FPS for Crysis at High settings and 1680x1050 resolution. Even my GeForce GTX 460 only achieves an average of 52.5 FPS during the benchmark.

>...and when asked to come up with some relevant applications that do
>not use compressed textures you mentioned Nexuiz and only Nexuiz. An open-source
>game. Based on a modified Quake 3 engine. Which also happens to make use of texture
>compression, just grep-ing the code shows it!

I've just proven that this is now totally irrelevant, but anyway, since you're asking for it... Please tell me exactly where in the code it is loading any compressed textures.

Grep isn't going to help you, because it's simply not there. Oh yes, the extension functions are there, but they're not being used anywhere!

>So the thing is, everybody is using
>compressed texture, even for high quality assets, they save memory, save bandwidth
>and make distribution methods and loading times shorter.

Saving memory isn't relevant to a software renderer because there's more system memory, and you only have to decompress the textures which are actually used in the scene.

It doesn't change the distribution method and loading time at all. SwiftShader supports all Direct3D 9 compressed texture formats. It just decompresses them before sampling (which is really fast). It happens completely transparenty to the application.

>You cannot do away without
>them, reality doesn't change only because you don't like it.

Yes you can do away with them, I've just proven it. Reality doesn't change only because you don't like it, either.

>Now, let's get to the performance and efficiency numbers just for the sake of it
>but before we do a not about bandwidth. You keep claiming that software rendering
>is not bandwidth limited - which is true - but the reason why it is not bandwidth
>limited as I already pointed out is that the performance is so low that the required
>bandwidth is ridiculously small. What you might want to do is to pick an application
>like a recent application at a meaningful resolution/detail, run it with VTune and
>measure bus utilization. Now if it runs at 1FPS like your Crysis example multiply
>that bandwidth by 30X and come back and tell us it wouldn't be bandwidth limited at that frame-rate.

It wouldn't be bandwidth limited at that frame-rate.

>But let's get at the actual performance data so I can show you how far off your claims are.
>
>>http://img510.imageshack.us/img510/3793/swiftshaderdefencegrid.png
>>
>>That's SwiftShader running Defence Grid at 1024x768, low detail, on a Core i7 920
>>@ 3.2 GHz. At 19 FPS it's perfectly smooth for this type of game. And it's full
>>quality 3D. With two cores it's playable at 800x600.
>
>OK, I've made a couple of tests on my box using this single point of data. I asked
>how this game would run on a 2.1GHz C2D and you tested it on an over-clocked, high-end
>i7 processor. That alone shows that you do not want to make meaningful comparisons.
>Still let's spend a couple of words on the game. At 19 FPS with less than 10 turrets/enemies
>on the screen that game is totally unplayable as on a normal level you will have
>tens, sometimes hundreds of them. You mention "full 3D quality" which is kind of
>a joke since in low detail it uses very poor quality textures, little transparencies,
>no post-processing and not even shading (i.e. in medium quality you get better quality
>textures, phong shading on materials and better effects). Now I've run the same
>scene you provided with FRAPS on my pityful HD2400 and obtained the following results (1024x768):
>
>Low quality 30 FPS
>Medium quality 20 FPS
>High quality 9 FPS

That's hardly any faster than SwiftShader, which is not yet using AVX and not using gather/scatter. Sandy Bridge is already 30% faster without any changes and it uses a lot less power, so with AVX and gather/scatter it's going to really put that HD2400 to shame.

Regarding "full quality" I was referring to the rendering quality, not the quality of the assets. It's not taking any shortcuts like some other software renderers.

>With a power-meter the difference between CPU-load only and playing the game was
>~7W at the wall, which means that the GPU is burning ~5W. Let's compare to your
>box by making the assumption that your overclocked CPU is consuming only 100W, that's
>pretty favorable and doesn't even take into account the memory which is included in my numbers.

I overclock my CPU to get slightly faster compile times. If I underclocked it, it would be a lot more power efficient without losing all that much performance. And Sandy Bridge is way more power efficient than my 45 nm Nehalem, and faster clock for clock too.

It's still not going to be 5 Watt, but that hardly matters. People who currently buy systems with an IGP are not very serious about gaming. So when they do play a game, it's fine to consome more Watts.

>This 65nm GPU is >30 times more power efficient than software rendering on a 45nm
>CPU. Probably more. And this chip happens to be slower and more power hungry than
>current IGPs. On top of that with GPU/MEM clocks of 450/400 MHz and single-channel
>DDR2 memory it has 1/3 of the GFlops and 1/7 of the bandwidth of your system. What
>does this tell you about relative efficiency of software rendering? Oh, and it's
>also 1/4 of the die size so here's how *inefficient* software rendering is and why
>it is not going to replace dedicated IGPs.

A dedicated sound chip could also be way more power efficient than a software codec. But noone cares!

Cheers,

Nicolas