I'm picking up from this older post of yours to bring some data in this discussion, I will try to make it streamlined to avoid your WOTs where you repeat the same things over and over again in the hope of making them true even if they aren't backed by any numbers and/or have been proven wrong.

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) 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! 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. You cannot do away without them, reality doesn't change only because you don't like it.

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.

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

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.

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.