Second part of my response:

Gabriele Svelto (gabriele.svelto@gmail.com) on 1/13/11 wrote:
---------------------------
>Nicolas Capens (nicolas.capens@gmail.com) on 1/12/11 wrote:
>---------------------------
>>As for compressed textures, they're not as critical as they may seem. Due to licensing
>>issues, popular S3TC based formats are still not part of core OpenGL.
>
>Compressed textures have been in core OpenGL since version 1.3. Specific compression
>techniques are left to the implementer, better get your facts straight.

That's what I said. The API is there but certain popular formats are not part of the specification. So when a developer wants to be sure that his application runs on all hardware, he can't use S3TC.

>>Loads of applications don't bother using them.
>
>Name a relevant application - especially games - that is not using compressed textures at all.

Nexuiz.

Despite the lack of compressed textures, it's the number one fast paced open-source first-person shooter.

Hardware support for compressed textures is not critical to the viability of software rendering. In bandwidth-limited situations, it only helps by about 10%. Off course in the case of a GPU you want that 10% since every cent you pay has to count, but for a CPU running graphics plus every other application, it's a different trade-off.

That said, it's not at all impossible to add texture decompression as a CPU instruction... But again it's a trade-off against using that die area for something that will benefit the CPU as a whole a bit more.

>>And low-end and mid-end hardware have higher bandwith:computing ratios so it's not that helpful.
>>
>>Where compression does help significantly is to fit everything in VRAM.

Exactly. But since software renderers have access to lots of system RAM, that's not really an issue. And the bandwidth issue is largely compensated by the CPU's big caches.

>Absolutely untrue, on low-end hardware you *need* the bandwidth savings from compressed
>textures even more than in the high-end. Especially on IGPs where VRAM constraints
>are not there since they're using system memory.

SwiftShader runs 30% faster on a Sandy Bridge chip with only 55% of the bandwidth. There is no clearer proof that software rendering isn't bandwidth limited.

And yes, it will become bandwidth limited at some point. But software rendering will be completely viable before that.

The trend is that the number of texture accesses is going down, relative to uncompressed unfiltered memory accesses. So the bandwidth savings is getting smaller. The reason for this is obvious: there's only so many textures you can slap onto your scene's geometry.

At the same time, caches are still getting bigger and bandwidth is still increasing. There are even strong indications that T-RAM technology is nearly ready for production. It combines the density of DRAM with the speed of SRAM. This means that sooner or later the majority of the data used in a frame will fit in the cache, further reducing the relevance of texture compression.

We're not there yet, I realize that, but nothing is stopping the steady convergence toward software rendering.

>>Ironically people with high-end hardware tend not
>>to like the quality loss of texture compression so they sometimes disable it.
>
>How do they do that? Well, I'm gonna tell you: they don't unless the application
>supports it. That's because assets in games are shipped in compressed form, so there's
>no way to "turn it off". Most high-quality assets are actually higher-resolution compressed textures.
>
>>The general trent is toward higher quality.
>
>Yeah, there's new compression standards coming out for that purpose:
>
>http://www.nvidia.com/content/nvision2008/tech_presentations/Game_Developer_Track/NVISION08-Direct3D_11_Overview.pdf
>
>Check out BC6H and BC7.

I know. Like I said, for GPUs it's fully justified to invest in texture compression. No argument there.

But what's the next step? Obviously there's a quest for higher quality so it was only a matter of time before compressed HDR formats became available so they actually fit in VRAM. But we don't really want compression; it's just a temporary necessity for dedicated gaphics. Once the bandwidth and VRAM goes up the purpose of compression diminishes again. There's not much beyond this, and if there is, it's not likely of interest to the markets that would show an interest in software rendering first.

>>But for software rendering that's far less of an issue
>>since you typically have about four times more system RAM. Note also that an i7
>>2600 has lower memory bandwidth than an i7 920 yet it's significantly faster so
>>software rendering isn't bandwidth limited.
>
>Yes, because it's much slower than hardware-accelerated rendering and you're hitting
>a different bottleneck: processing power. Let's put it this way, when doing rendering
>on the CPU you're wasting so many cycles on calculations that you're never gonna
>be bandwidth limited. That's why adding scatter/gather will not make CPU-based rendering
>competitive. Look at it from another angle: SB IGP's ALU throughput is *less* than
>the CPU's ALU throughput while still being at least 5 times faster in 3DMark06 according to your numbers.

SwiftShader is not yet using AVX.

But even if it was, there's still a significant gap and indeed it's not due to a lack of GFLOPS. So CPU manufacturers should have a good look at how that's possible. It's not lack of bandwidth or compressed textures either. Dedicated rasterization then? Nope, that's also a very minor task.

To me it's very clear that the lack of parallel load/store is a huge bottleneck. The ALU's can do 16 operations in parallel, but only 2 load operations and 1 store operation can be executed per clock. And it gets worse with FMA.

Gather/scatter would speed up texture sampling, vertex attribute fetch, primitive setup, rasterization, transcental functions, raster operations. It's incredibly versatile and responsible for a large chunk of the remaining CPU-GPU gap.

>>Why not try it instead of "basing" yourself on the 3DMark06 score? I have yet to
>>find a game in Steam's casual section which doesn't run fine with SwiftShader on
>>a quad-core CPU. Some even run smoothly with anti-aliasing.
>>3DMark06 is a synthetic
>>stress test designed to benchmark the hardware at the time of release, and still
>>offer a challenge to future graphics solutions. Even today's casual games are nowhere
>>near as complex as 3DMark06. And that's not likely to change fast. Causal games
>>are designed to run on the lowest common denominator, which includes older IGP's like the X3100.
>
>Pointers? I'm playing Defense Grid right now, pretty light game. If I try it on
>my laptop with its measly Radone HD2400 it can run at 1024x768 with all detail turned
>off. It's far from pretty and still dog slow but it runs, what about running it
>with SwiftShader on the processor, a C2D? Defense Grid is totally unplayable on
>an X3100. And that's a casual games which is already two years old. If by casual
>games you mean 2D games using 3D hardware then that's another story but honestly those run well *everywhere*.

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.

But I'm talking about future processors. Sandy Bridge is 30% faster without any changes. Imagine having six cores, making use of AVX, and gather/scatter. This game would easily run at 60 FPS with high detail, and the power consumption would still be reasonable. This technology is well within reach, and is only getting cheaper.

So in five years or so people who don't need cutting-edge graphics will have plenty of graphics power from their CPU cores.

>>For your information, SwiftShader will be used in future versions of Flash to enable 3D casual games on the web, when you don't have adequate graphics hardware: http://blogs.adobe.com/flashplatform/2011/01/digging-more-into-the-molehill-apis.html
>
>Well that's nice to hear, but offering a fallback for incompatible hardware or
>drivers doesn't mean that software shading is competitive with IGPs, let alone threatening them.

True, but it's evolving from merely a fallback, into a viable alternative. Sooner or later system builders will realize they no longer need a GPU or an IGP to create a system that's still capable of adequate 3D support.

>>But that's one outer end of the application area. You appear to be stuck thinking about what's possible with today's systems. Sandy Bridge's performance per Watt is already double that of the previous generation: http://www.pcper.com/article.php?aid=1057&type=expert&pid=12.
>>> Now imagine that in two more generations we will have four times higher performance
>>per watt, and gather/scatter support, and tell me again it will never be viable
>>to have GPU-less systems even for the low-end market.
>
>The lowest end market with the tightest space, power and area constraints - mobile
>phone - is going from GPU-less to GPU-enabled. You keep ignoring the very basic
>fact that we're getting more GPUs and faster ones precisely in the low-end. They're
>not going away, they offer better performance at lower price and power, no scatter/gather
>instruction will ever make it different.

Low-end does not mean mobile! The fact that mobile devices are getting GPUs does not mean a single thing for the CPU-GPU convergence that is going on in the desktop market. There's a giant market for office systems, which need good CPU performance, but the cheapest possible graphics solution. Since 3D is coming to desktop applications and the web, some level of 3D graphics support is still neccessary, but clearly software rendering can offer the ideal compromise at the lowest price.

By the way, I was talking about low-end graphics, not low-end systems. Current systems with an IGP are not necessarily low-end, but they have a low-end graphics solution. There's no denying there's a market for which a bit less graphics performance is acceptable too, if it costs less.

To be continued...