Hi David,

David Kanter (dkanter@realworldtech.com) on 1/27/11 wrote:
---------------------------
>>Doom 3 on a GTX 460 at 2560x1600 4xAA runs at 53 FPS at >Ultra High Detail, and
>>at 56 FPS at High Detail. I was being generous when I said >10%.
>
>That shows nothing about compression, that merely tells about the change in performance
>due to larger textures. It's also largely about an older game that isn't designed for 2560x1600.

The change in performance is the whole point.

Doom 3's uncompressed textures are equal in dimensions to the compressed ones.

>What I'd want to see is for a number of MODERN games:
>
>1. Texture size (uncompressed vs. compressed)
>2. Bandwidth usage (uncompressed vs. compressed)

Texture size is irrelevant. They can be kept in compressed form when unused. Only a fraction of all the texture levels is needed during a frame.

And I've tested 3DMark06 with SwiftShader while forcing the mipmap LOD down one level (which is equivalent to reducing the texture bandwidth by a factor 4), and the SM3.0 score went from 250 to 249. Yes, due to some statistical variance the score was actually lower. If texture bandwidth was of great significance, you'd expect a much higher score.

>You're claiming that for #2 the difference is 10% and I don't see any real evidence
>of that. Compression should be vastly more effective.

Texture compression rates of 1:2 and 1:4 are very common, but that doesn't translate into big performance improvements. Most of the time there's sufficient bandwidth headroom to allow uncompressed textures without an impact on performance. And even in bandwidth limited situations, there's already a large chunk of it used by color, z and geometry. So the performance won't drop by much.

>>To clarify this result somewhat, here's the bandwidth usage of Unreal Tournament 2004 at 1024x768, using compressed textures: http://personales.ac.upc.edu/vmoya/img/bw.png
>>
>>Although bandwidth usage differs a lot between games, we can observe a few things
>>which reduce the impact of texture compression. First of all, games aren't memory
>>limited all the time. The memory bus is overdimensioned to prevent that from happening
>>too frequently. It means that even if the bandwidth requirement would double, the
>>performance would not reduce in half. Also note how color and Z each take a very
>>significant amount of bandwidth. And the balance tips over >even further with deferred rendering.
>
>I happen to know the author of that study in question. The data is INCREDIBLY
>OLD. It's from a simulator that did not use any Z or color compression, so the results cannot be taken seriously.

Yes, it's from a simulator called ATTILA. And for the record it did use z compression to generate that graph.

And even though it's old, this data is still very relevant. UT2004 has a very high TEX:ALU ratio, meaning that contemporary games are far less likely to become bandwidth limited. UT2004 also has simple geometry and no pre-z pass, again meaning that texture bandwidth has only become less relevant with newer games.

>>Note that in the case of Doom 3, the main reason for not disabling texture compression
>>was VRAM size. When textures had to be swapped in and out over the AGP or PCIe bus
>>the performance hit was huge, but it wasn't a VRAM >bandwidth issue.
>
>>For a GPU the texture decompression logic is worth it >mainly to keep VRAM size
>>smaller (read: cheaper). The bandwidth savings are a >welcome bonus but I doubt
>it would be a justification by >itself.
>
>I think you underestimate the cost of adding pins to your memory controller.

I'm not suggesting adding extra pins to make software rendering viable. It's already viable bandwidth-wise.

Multi-core is driving the bandwidth needs up for all applications, so I'm confident that it will be increased anyway in due time. But there's no need for additional dedicated hardware. The caches do an excellent job at reducing the overall bandwidth needs.

>>>>That said, it's not at all impossible to add texture >decompression as a CPU instruction...
>>>
>>>Won't happen.
>>
>>That was my conclusion as well. They would never add instructions which could become
>>of little or no use in several years.
>>
>>I merely mentioned it to note that there's nothing a GPU can do, which a CPU could
>>not possibly do. Also, there are plenty of other alternatives, should it be necessary.
>>And again, it doesn't have to match the efficiency of >dedicated hardware to be viable.
>
>Actually for the mobile space it does have to come close to dedicated hardware. Battery life matters, a lot.

For laptops we see the graphics solution range from IGPs to lower clocked high-end desktop GPUs. So while battery life is important, it doesn't mean the TDP has to be the lowest possible. It just has to be acceptable. A cheaper IGP which consumes more power is likely to sell better than a more expensive efficient one. Also note that today's GPUs have far more features than the average consumer will really use, meaning they are less energy efficient than they could have been. But the TDP is still acceptable for a good battery life.

Furthermore, nobody expects a long battery life during intense gaming. Even with dedicated graphics hardware the power consumption during gaming is relatively high. So instead of a multi-core CPU with an IGP you might as well have a CPU with a couple more cores. As long as the TDP is the same, it's acceptable.

>>Most likely the bandwidth will just steadily keep increasing, helping all (high
>>bandwidth) applications equally. DDR3 is standard now accross the entire market,
>>and it's evolving toward higher frequencies and lower voltage. Next up is DDR4,
>>and if necessary the number of memory lanes can be >increased.
>
>More memory lanes substantially increases cost, which is something that everyone wants to avoid.

They'll only avoid it till it's the cheapest solution. Just like dual-channel and DDR3 became standard after some time, things are still evolving toward higher bandwidth technologies. Five years ago the bandwidth achieved by today's budget CPUs was unthinkable. So frankly I don't care how they'll do it in the future, but CPUs reaching 100's of GB/s of bandwidth will sooner or later be perfectly normal.

>>And again CPU technology is not at a standstill. With >T-RAM just around the corner
>>we're looking at 20+ MB of cache for mainstream CPUs in >the not too distant future.
>
>T-RAM is not just around the corner.

This news item suggests otherwise: http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090518005181

But even if it does take longer, it doesn't really matter to the long-term viability of software rendering. There will be a breakthrough at some point and it will advance the convergence by making dedicated decompression hardware totally unnecessary (if it even has any relevance left today).

>>And while the expectations for 'adequate' graphics go up as well, it's only a slow
>>moving target. First we saw the appearance of IGPs as an adequate solution for a
>>large portion of the market, and now things are evolving >in favor of software rendering.
>
>I think if you look at the improvement in IGPs, that's a very FAST improving target.

The hardware isn't the target. Consumer expectation is the target. Sandy Bridge leaves a hole in the market for consumers who want a powerful CPU but are content with minimal graphics support.

>>>>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.
>>>
>>>That's only meaningful for swiftshader, not all SW rendering. How does it work
>>>with MSAA and anisotropic filtering and other more advanced techniques?
>>
>>I don't see why it would only be "meaningful" for SwiftShader. The public demo
>>does not take advantage of Sandy Bridge's new features. So >I expect other software
>>renderer's to benefit roughly the same.
>
>Swiftshader is swiftshader - other SW rendering systems work differently. They may (or may not) see similar benefits.

Again, why does that make SwiftShader's results only "meaningful" for SwiftShader?

All reviews only include a select number of benchmark applications. Does that mean the results are meaningless for other applications? Of course not.

Unless you can give me any sort of indication how another software renderer with Shader Model 3.0 support could be bandwidth limited, 30% higher performance with 55% of the bandwidth is extremely meaningful for any such software renderer.

You seem to be suggesting that SwiftShader is doing something wrong which makes it 30% faster with 55% of the bandwidth. If that's the case, great! It means that things can get much faster still.

>>I haven't had the chance yet to see how Sandy Bridge >performs with multi-sampling,
>>but I'll keep you posted when I do. Anisotropic filtering >doesn't seem relevant
>>to bandwidth, since all texels will be in cache due to >high temporal coherence.
>>In fact it would make it even more gather/scatter limited.
>
>>>Also, what is your comparison against? It sounds like you're saying Sandy Bridge
>>>has 55% more memory bandwidth than whatever your baseline is...which sounds like
>>>an awful lot. Sandy Bridge's memory controller isn't that much faster than Arrandale AFAIK.
>>
>>No, I said Sandy Bridge has only 55% of the bandwidth of my baseline, which is
>>an i7 920 @ 3.2 GHz, using 1600 MHz memory and three channels. So if I'm not mistaken
>>that's 1.85 times the memory bandwidth versus the i7 2600 >I tested. Despite that, the 2600 is 30% faster!
>
>I don't know what an 7 920 is, but if it only has 4 cores, it cannot really utilize the memory bandwidth.

http://ark.intel.com/Product.aspx?id=37147

>Also, note that there are big differences in the cache hierarchy.

Exactly. If there was any lack of bandwidth in the first place, it's clearly compensated by other CPU technology. I don't see the slightest indication that software rendering will become bandwidth limited any time soon.

The most likely explanation for the fact that SwiftShader is 30% faster on Sandy Bridge is probably the dual load units. Which means a gather instruction would increase performance further, especially with 256-bit AVX.

If you have a better explanation, please tell me because it probably means SwiftShader could be even faster.

>Perhaps a more interesting question to ask is to take Sandy Bridge and start downclocking
>the memory and seeing what the performance degradation is. Comparing two totally
>different systems tells you very little about memory bandwidth.

I don't have a Sandy Bridge system yet (and the chipset bug probably means it will take another month). But feel free to benchmark it yourself. The public demo is fully featured.

Anyway, to meet you in the middle I downclocked my i7-920's memory from 1600 MHz to 960 MHz, and the 3DMark06 SM3.0 score went from 250 to 247. So once again, reducing the bandwidth to 60% has no significant impact on performance.

>>So again, software rendering is nowhere near being RAM >bandwidth limited. Just like many other compute intensive >applications, it needs gather/scatter before any other >parameter starts to matter. Note that gather/scatter >wouldn't just allow a massive reduction in the number of >serial load/store instructions, it would also reduce the number of swizzle operations: http://software.intel.com/en-us/forums/showpost.php?p=139770
>
>Reducing the number of loads and stores isn't really relevant. It's the number
>of operations that matters. If you are gathering 16 different addresses, you are
>really doing 16 different load operations.

Not with Larrabee's implementation. It only takes as many uops as the number of cache lines that are needed to collect all elements, per load unit.

>>>>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.
>>>
>>>Then you just increase the geometry count, or use tessellation. It seems like
>>>geometry would scale at the same rate (or maybe a bit slower) than texturing.
>>
>>With all due respect, you're sounding a bit like the >people who said dedicated
>>vertex and pixel pipelines make more sense than a unified >architecture because
>"you just increase the geometry >count".
>
>No, that's totally different. With unified shaders you can easily use more or
>less geometry...until you run out of physical shaders to execute on. You should
>look at Kayvon's work on micro-polygon rendering.

Easily? I think you're seriously underestimating the complexity of adapting your software to the hardware. Checking whether you're vertex or pixel processing limited wasn't feasible in actual games ten years ago, and it still isn't.

Fatahalian's article doesn't address this issue either. It raises more questions than it answers, really. Micropolygon rendering is just one out of many techniques. Some applications may use it, a lot won't. A flat wall is still a flat wall and tesselating it is just a waste of computing power (not to mention electrical power). And for applications that don't use it, any additional dedicated hardware is a waste of silicon. To efficiently support micropolygons, ray-tracing, Reyes, a multitude of GPGPU applications, etc. they need to make rasterization and texture sampling programmable. Software developers don't want a fixed architecture that can only be used in one way.

To get back to compressed textures, you continue to prove my point. If micropolygons are the dominant future technique, the vertex processing workload will increase drastically. Since it uses uncompressed vertex attribute data, the relative bandwidth savings from texture compression continues to drop.

>>It's clear that telling software developers what (not) to >do doesn't result in
>>a succesful next generation hardware architecture. With >non-unified architectures,
>>there were numerous applications which were vertex >processing limited, and numerous
>>ones which were pixel processing limited. And even those >in the middle have a fluctuating workload.
>
>Yes, except a unified shader architecture doesn't really preclude that many options.

That's what I'm saying.

>>So instead hardware architectures should accomodate to the >increasing variety in
>>workloads. This means generalizing the texture units into >gather/scatter units and
>>performing filtering in the shader units.
>>
>>Anyway, you were probably still referring to bandwidth? Then increasing the amount
>>of geometry in the scene won't tip the balance in favor of texture compression.
>>With deferred shading or pre-z passes additional geometry only increases the color
>>and/or z bandwidth needs (on top of the geometry bandwidth of course). Tesselation
>>can make use of compressed textures, but note that it's sampled at a low frequency.
>>Plus it massively increases the vertex processing workload, so in fact you're less
>>likely to get bandwidth limited at all.
>
>>>>At the same time, caches are still getting bigger and >bandwidth is still increasing.
>>>
>>>That's not the question. It's 'are caches increasing in >>size sufficiently faster than texturing data'.
>>
>>Absolutely. Ten years ago the L2 cache was 256 kB, nowadays we have 8 MB of L3
>>cache. That's 32 times more. Games did not evolve from ~2 >to ~64 texture samples
>>per pixel.
>>Even if you count in the increased screen resolution and >additional scene
>>complexity (which by the way also scale the computational >needs), the texture bandwidth
>>needs did not increase 32-fold. Even for the high-end the >memory bandwidth has not
>>increased by that much. And it increased far less in the >low-end graphics market.
>>IGPs are focussing on increasing their computing power >more than their texturing abilities.
>
>First, you do need to count the increases in resolution. Pixels have definitely
>increased over time.

Yes the resolution has increased but everything else scaled accordingly. More pixels doesn't mean higher benfit from texture compression. In fact TEX:ALU is going down, meaning pixel shaders are more compute limited than bandwidth limited.

>And TBH, I don't have any numbers on how fast the texture
>sizes have increased. I suspect quite a bit.

Texel size or texture dimensions?

Texture dimensions are irrelevant. The bandwidth need for an unmagnified texture sample is on average one texel per pixel. The additional texels accessed for filtering are all perfectly cachable.

>>In ten more years caches could be around 256 MB, and >that's without taking revolutionary
>>new technologies like T-RAM into account. So it's really >hard to imagine that this
>>won't suffice to compensate for the texture bandwidth >needs of the low-end graphics market.
>
>Because you are imagining that the low-end market stays put. It won't.

I didn't say it stays put. I said it's a slow moving target. Evidence of this is the ever growing gap between high-end and low-end graphics hardware. IGPs were born out of the demand for really cheap but adequate 3D graphics support. They cover the majority of the market:
http://unity3d.com/webplayer/hwstats/pages/web-2011Q1-gfxvendor.html

This massive market must obviously have a further division in price and performance expectations. Some people want a more powerful CPU for the same price by sacrificing a bit of graphics performance, while others simply want a cheaper system that isn't aimed at serious gaming. As the CPU performance continues to increase exponentially, and things like gather/scatter can make a drastic difference in graphics efficiency, software rendering can satisfy more and more people's expectations, even if those expectations themselves incease slowly.

>>SwiftShader 1.0 was first used by a 2D casual game called Galapago. Despite the
>>game's graphical simplicity, it was totally texture sampling limited and it was
>>barely reaching the necessary 10 FPS for playability. That >was five years ago.
>Today we have Crysis running at 20+ >FPS.
>
>What resolution and quality settings?

800x600 at low detail. It's twice as fast as Microsoft WARP: http://msdn.microsoft.com/en-us/library/dd285359.aspx

>>I don't need any crystal ball to see that gather/scatter >will make IGPs redundant.
>
>That's because it won't.

It will. The only strengths the GPU has left are all components based on the ability to load/store lots of data in parallel. The CPU cores already achieve higher GFLOPS than the IGP, so gather/scatter unlocks that power for graphics applications. You can either ditch the IGP to make things cheaper, or replace it with additional CPU cores so you get a really powerful processor for any workload.

>>http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090518005181
>
>That means nothing. It means that GF is investigating the technology, not that it's production ready.

Quoting the announcement: "...into a joint DEVELOPMENT agreement targeted toward the APPLICATION of T-RAM’s Thyristor-RAM embedded memory..."

Emphasis mine. Why would a major foundry enter into a development agreement with a startup, unless the technology has already been proven on a smaller scale?

Quoting http://www.t-ram.com/news/media/3B.1_IRPS2009_Salling.pdf: "Taken together, the results of this study show
that T-RAM is a reliable and manufacturable memory
technology."

Quoting t-ram.com: "T-RAM Semiconductor has successfully developed the Thyristor-RAM technology from concept to production-readiness. Our Thyristor-RAM technology has been successfully implemented on both Bulk and SOI CMOS. "

Sounds like production ready to me.

>>Anyway, there are multiple high density cache technologies. There's Thyristor-RAM,
>
>That's T-RAM.

I know. I was just summing up "high density cache technologies".

>>1T-RAM,
>
>Not a replacement for SRAM.

Why not? Looks useful as L3 cache to me.

>>2nd gen Z-RAM
>
>Doesn't work at all.

Maybe not as cache memory, but it's hopeful as a DRAM replacement: http://www.z-ram.com/en/pdf/Z-RAM_LV_and_bulk_PR_Final_for_press.pdf

>>Together with gather/scatter this helps the CPU compensate
>>for its lack of dedicated texturing hardware, allowing it >to significantly gain
>>on GPUs. So sooner or later software rendering is going to >take over the low-end graphics market.
>
>It's possible, but they will need to become more competitive from an energy perspective with fixed function stuff.

There's not a lot of fixed-function stuff left. The majority of the GPU's die space consist of programmable or generic components.

And I've shown before that the CPUs FLOPS/Watt is in the same league as GPUs:
- Core i7-282QM: 150 GFLOPS / 45 Watt (more with Turbo Boost)
- GeForce GT 420: 134.4 GFLOPS / 50 Watt

Obviously software rendering requires a bit more arithmetic power to implement the remaining fixed-function functionality, but programmable shaders take the bulk.

So there's no lack of energy efficiency. The CPU simply can't utilize its computing power effectively

>Audio consumes an insignificant number of cycles. Miniscule.

During the early days of AC'97 there was some pretty serious debate about moving the audio processing workload to the CPU. It made a real difference in benchmark results. People who back then swore by the efficiency of dedicated sound cards, now happily use HD Audio.

>Perhaps when graphics
>gets to that point, it will be fine to put it in SW.

Exactly. There's no doubt it will happen, some day. My take is that gather/scatter support is sufficient to initiate the move to software rendering.

>And yes, power efficiency matters a lot. You may not think so, but it does.

I do think it matters, a lot. But I think you're underestimating how power efficient CPUs already are. It just doesn't translate into high effective performance for 3D graphics due to wasting a lot of cycles on moving data elements around.

An AVX FMA instruction can perform 16 operations every single cycle, but it would take a whopping 72 uops if every address and element was extracted/inserted sequentially. When it comes to load/store, we haven't evolved beyond x87 yet. Of course this is the worst case and typically not every vector load/store has to be a gather/scatter, but for situations where you do need them it makes a massive difference.

>>Sandy Bridge is designed to be able to use four cores plus an IGP, all within 95
>>Watt. During gaming or other intensive applications, that's perfectly acceptable.
>>As you know, Sandy Bridge is amazingly efficient. So it should be equally acceptable
>>to trade the IGP for two more CPU cores, add gather/scatter capabilities, and as
>>a result get a really powerful CPU which can also take >care of graphics, all within 95 Watt.
>
>I don't think you design CPUs for high volume applications. Most don't need scatter/gather
>and the hardware cost is high.

All applications that contain loops can benefit from gather/scatter. That's all applications.

With sather/scatter support every scalar operation would have a parallel equivalent. So any loop with independent iterations can be parallelized and execute up to 8 times faster.

And I don't think the hardware cost is that high. All you need is a bit of logic to check which elements are located in the same cache line, and four byte shift units per 128-bit load units instead of one, to collect the individual elements. Note that logic for sequentially accessing the cache lines is already largely in place to support load operations which straddle a cache line boundary.

>>>>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.
>>>
>>>You always want compression for something you store in memory. It increases effective
>>>bandwidth and reduces capacity used. You might want higher fidelity or lossless
>>>compression, but you'll still want it. Less memory traffic is lower power and fewer pins.
>>>
>>>>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.
>>>
>>>Again, only sort of. There's always a benefit to compression.
>>
>>You don't unconditionally want it. It's still a trade-off. >For this reason lossless
>>compression of system memory is hardly more than a >conceptual idea. Apparently it's
>>cheaper to increase the bandwidth and capacity the brute >force way.
>
>Really? Have you heard of Vertica? They do an awful lot of lossless compression of data in memory.

No, I hadn't heard about them before. Could you point me to some document where they detail how they added hardware support for compressed memory transfers to reduce bandwidth?

>>>>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.
>>>
>>>Um, Sandy Bridge can do 32B/cycle of loads, that's 8 >values.
>>
>>It can load 2 x 4 *consecutive* 32-bit values (per core >per cycle). That's not
>>the same as 8 values. As illustrated in the link I gave >above, that's worthless
>>for something like a parallel table lookup.
>
>Many applications use adjacent values.

Yes, and many applications also use non-adjacent values.

If a loop contains just one load or store at an address which isn't consecutive, it can't be vectorized (unless you want to resort to serially extracting/inserting addresses and values). So even if the majority of values are adjacent, it doesn't take a lot of non-adjacent data to cripple the performance.

>>>That's part of it...but scatter/gather generally means you MISS in the cache/TLBs and chew up more bandwidth.
>>
>>Why? It only accesses the cache lines it needs. If all >elements are from the same
>>cache line, it's as fast as accessing a single element.
>
>And exactly as fast as using AVX! i.e. no improvement and more complexity/power.

No. The addresses are unknown at compile time. So the only option with AVX1 is to sequentially extract each address from the address vector, and insert the read element into the result vector. This takes 18 instructions.

With gather support it would be just one instruction. Assuming it gets split into two 128-bit gather uops, the maximum throughput is 1 every cycle and the minimal throughput is 1 every 4 cycles.

>>But even in the worst case
>>it can't generate more misses or consume more bandwidth.
>
>It sure can. Now instead of having 1-2 TLB accesses per cycle, you get 16. How
>many TLB copies do you want? How many misses in flight do you want to support?

You're still not getting it. It only accesses one cache line per cycle. It simply has to check which elements are within the same cache line, and perform a single TLB access for all of these elements. Checking whether the addresses land on the same cache line doesn't require full translation of each address.

>>Once the IGP has gone the way of the dodo, more powerful >CPUs can be created for
>>people who want mid-end graphics performance. I bet Intel >would really love selling
>>quad-channel 12-core CPUs not just to the server market but to gamers as well. Sandy
>>Bridge already pretty much made the low-end discrete graphics cards obsolete, and
>>Intel is not likely going to lose its grip on that massive >market.
>
>I'm sure they'd love to, but they won't. Some things run better on dedicated hardware
>than not. It's possible some dedicated hardware will migrate into the core...but not guaranteed.

Nothing other than graphics runs better on the IGP. As I've mentioned before, GPGPU is only succesful using high-end hardware.

So the CPU is better than the IGP at absolutely everything else. That makes it really tempting to have a closer look at what it would take to make it adequately efficient at graphics as well.

The answer: gather/scatter.

>I think one of the points people are raising is that CPUs are generally latency
>oriented devices, whereas scatter/gather tends to be more useful in the context
>of throughput devices. That suggests that to some extent scatter/gather in the
>GPU (i.e. throughput device) is the right approach...instead of trying to make the CPU into a throughput device.

Multi-core, 256-bit vectors, Hyper-Threading, software pipelining... the CPU is already a throughput device! It's just being held back by the lack of parallel load/store support. It's the one missing part to let all those GFLOPS come to full fruition.

The architecture of the future balances ILP, DLP, and TLP. GPUs also started to embrace ILP (with true superscalar instruction scheduling), and TLP (with concurrent kernel execution). They still have a long way to go to become good at anything other than graphics though. It's just never going to happen. If the IGP becomes capable of anything other than graphics, it will be very CPU-like so it makes no sense to keep it a heterogenous architecture.

Long before IGPs can even be considered for GPGPU applications, the CPU will have support for the last few missing instructions to turn it into an efficient throughput device.

>>Not necessarily. Opting for an IGP means accepting a less >powerful CPU.
>
>It doesn't though - it merely means fewer CPU cores. Look at Sandy Bridge for
>consumers versus the EP version. The difference is in the core count. You cannot
>simply afford to create different CPU cores for folks who want IGPs and those who don't. THat's bad economics.

The CPU core is the same for everyone, and kicking out the IGP for some models is cheap. As I've mentioned above gather/scatter is useful for practially any application.

>>I know
>>plenty of people who would buy a laptop with a more >powerful CPU instead, if it
>>costed the same and the graphics were adequate for their >everyday experience.
>
>I think you're missing the point. Right now, it appears like the trade-off is # of CPU cores vs. graphics.

There's HD Graphics 2000 and 3000. Surely there's room for HD Graphics 1000 if it means you still get a very powerful CPU.

>>Seriously, let's analyze the case of the GMA 950. It sucks donkey balls (pardon
>>my French). There's no excuse for buying it if you care >even a little about graphics.
>>Right? Despite having all odds against it, massive numbers >of this IGP were sold
>>in dual-core laptops, Mac Mini's, set-top boxes, etc. A >lite version (!) of this
>>architecture will even make it in lots of Smart TV's as >part of the Intel CE 2110
>>SoC. Lots of products based on this chip are still to >appear. Where does this
>commercial success come from? It's >cheap.
>
>It's also power efficient. At this point, it's not clear that SW rendering is
>comparably efficient and I'd argue it's unlikely to be without specialized hardware.

What specialized hardware would that be? I've already shown that texture compression hardly makes a difference, and sampling and filtering is becoming programmable anyway. Gather/scatter speeds up just about every other pipeline stage as well.

>>So people's expectation of adequate graphics can be very >low. But Sandy Bridge
>>actually offers more performance than these people need. >Software rendering can fill the void, as it's even cheaper.
>
>You're assuming that people's appetite for graphics stays constant, which isn't a good assumption.

I'm not assuming it stays constant. I'm assuming it's a slow moving target. It's impossible to prove what people want or don't want, but I personally believe there are strong enough indications that there's a market for software rendering if the efficiency is cranked up using gather/scatter. And because of the strong indications that CPUs and GPUs continue to converge that market is only getting bigger.

>>For a 500$ system with a 10% margin, it would increase >profit by 10% to not include that IGP. So 5$ is a lot.
>
>Yes, but you can charge more for the system since it gets better battery life.

No you can't, because the competition will sell it for less and take away your market share.

>>Furthermore, gather/scatter doesn't just help make >software rendering viable, it
>>helps a whole range of multimedia applications, including >some that have not yet
>>seen the light of day. So you'd be selling a very >attractive system if you spent
>>that 5$ on generic CPU technology instead.
>
>I totally agree that scatter/gather is a great capability to have. But what's
>the cost in die area, power and complexity? Not just to the core, but also the memory controller, etc.

Larrabee has wider vectors and smaller cores, but features gather/scatter support. So I don't think it takes a lot of die space either way. It doesn't require any changes to the memory controller, just the load/store units. I'm not entirely sure but collecting four elements from a cache line can probably largely make use of the existing network to extract one (unaligned) value. And checking which addresses land on the same cache line is a very simple equality test of the upper bits.

Cheers,

Nicolas