Hi Seni,

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, 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. It allows to have multiple independent samplers with each its own texture cache. Since they process different texture instructions, the caches have better locality.

>And it's a state (registers) issue, not a computational issue, so changing the speed doesn't help.
>You might be able to factor out the part that can be done to separate pixels and
>issue it off to a separate non-group-of-four unit, but it just makes things more
>complicated and provides no real benefit.
>Which is why no one has ever done it this way and they probably never will.

Rest assured some ultra-mobile graphics chips have singular texture samplers but still support dependent texture reads.

>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, can do 69 GFLOPS, and according to Wikipedia has a texture fillrate of 4.712 GT/s.

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)?

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.

>>It's not mostly texture-limited. At 1024x768 and 60 FPS, 5.4 GT/s suffices to use
>>229 texels per pixel. That's insanely high for the type of games you can run on
>>the IGP at this resolution and framerate.
>
>Ok, firstly, you messed up the arithmetic. 5.4e9/(60*1024*768) is about 114.4 not 229.
>Secondly, 1024x768 is kinda low. For a 1600x1050 screen it's only 53 texels per
>clock. For a 1900 x 1200 @ 50Hz it's only 47.
>Thirdly, 114 texels per pixel isn't really a lot.

Sorry, I must have used 30 FPS in my calculation.

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.

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. 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.

The simple reality is that texture operations are a special type of load/store which is only used sporadically. A homogeneous CPU with gather/scatter doesn't suffer from this because gather/scatter is a much more general type of load/store and it's used by a lot more than just texture sampling.

>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. There's just no way a contemporary game using high quality setting is going to run at decent framerates on this IGP.

>>Also note that gather/scatter typically makes no guarantees about memory ordering
>>(unlike unaligned accesses which straddle a cache line). Fence instructions can
>be used to flush the load/store buffers.
>>No, it's far simpler than you think. Let's say we have a base address of 0x0123456789ABCDEF,
>>and two of the offsets are 0x00000000 and 0x00000080. Are these two elements located in the same cache line?
>
>Ok, we went over this in another post. I mis-estimated some of this stuff.
>25 bits is enough if you do base + vector_of_indices addressing.
>
>>Also note you don't need to compare all possible pairs. You just start with the
>>first element and see which other elements are on the same cache line. If one isn't
>>on the same cache line, it's loaded in the next cycle and the other offsets are
>>compared to this element's offset to determine which ones share this other cache
>>line, etc. No need to compare everything in one cycle.
>
>I hadn't thought of that, so I was wrong about this.
>
>>Yes, and it's not going to get much better any time soon: http://www.anandtech.com/Show/Index/4083?cPage=23&all=False&sort=0&page=13&slug=the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested
>>"The 82.4% increase in clock speed resulted in anywhere from a 0.6% to 33.7% increase in performance."
>
>They increased the GPU clock but not the memory bandwidth. This resulting in poor scaling.
>Increasing GPU clock but not bandwidth has always resulted in poor scaling. Nothing new here.
>How this shows anything about trends in future hardware is beyond me.

It shows that the die area percentage for the IGP can't simply be increased in the next generations to save it from its fate. Certain people here insist on comparing theoretical compute density but fail to see the bigger picture. The CPU is catching up and unification gives it an area advantage, which can also be traded for reduced power consumption.

In particular it means that as the convergence reduces the gap, the IGP is the first to go.

>>The CPU is catching up and clearly there's little point in investing more die space
>>into the IGP. So CPU manufacturers should look into using the die space for something
>>more interesting, or cut it out entirely.
>
>They cannot use the die area for something more interesting, since IGPs are maximally interesting.

With all due respect that's as short-sighted as saying the architecture of an R300 is the maximally interesting use of 195 mm2 of silicon. Beyond low-end graphics, the IGP's capabilities are pathetic so you can forget about GPGPU. There's a lot to be improved.

More interesting GPUs (programmability) and more interesting CPUs (throughput) are released every major generation. So they're on a collision course. Replacing the IGP with two more CPU cores makes the use of that die area a lot more interesting because they can then be used in combination with the already existing CPU cores.

>>>>There's not supposed to be separate market segments, other than high-end, mid-end, and low-end.
>>>
>>>What???
>>>You must be masterly with the English longbow.
>>
>>I think I've clarified by now that eventually there's just 'computing'. A homogenous
>>CPU with FMA and gather/scatter can handle both latency-sensitive and high-throughput
>>workloads (and most applications are a complex mix of these). So the main thing separating the markets is price.
>
>There are many market segments separated by more than price, and your refusal to see them is baffling.

Other than CPUs and GPUs, which are converging, I don't see what else could be relevant to the discussion. So instead of implying I refuse to see them, why don't you show them?

>>Again, most applications are a complex mix of workloads. But even if some tend
>
>No they aren't. It's not a complex mix.

Have you ever taken a look at the various shaders used by a various games? They differ significantly. And they would differ even more if the GPU wasn't so restrictive. Like you said yourself, sometimes a texture access is replaced by procedural code and sometimes arithmetic code is replaced by a texture lookup, to better match the architecture. A more unified architecture would allow to use the operations they intended to use, and get a net speedup.

As a matter of fact that's what I've already observed for the past decade. In the early days there were no dependent texture lookups so some effects were simply not possible or there was usually just one workaround with acceptable performance. This and other limitations made every game look like a clone of other contemporary games (not in gameplay but in graphics), which started to change as the capabilities expanded. The unification of vertex and pixel processing also allowed developers a lot more freedom in the workloads, between applications but also between scenes in the same application. Floating-point textures and render buffers enabled deferred shading, which differs quite radically from previous approaches. And that's just the things that immediately popped into mind, and I wasn't even just talking about graphics. Other applications you may run on your system also have diverse and complex mixes of workloads.

There's really no denying that GPUs have become more programmable and more capable at handling this melting pot. And with GPGPU and future graphics research hinting at ray-tracing and micro-polygons and whatnot there doesn't appear to be an end in sight. At the same time CPUs have increased their throughput using multi-core and widening the vectors, and FMA and gather/scatter will make them even better at running more than just latency sensitive workloads. So with both aiming to support both types of workloads, a showdown is inevitable.

Note that there isn't any strict dividing line between them. You can't offload every high-throughput task to the GPU and execute every low-latency task on the CPU. Unless you have a massive amount of data parallelism to exploit it's faster not to send things over to the GPU and just process things on the CPU. The communication latency is too high and the bandwidth too low. It's better to unify things and keep the data local. Likewise, the GPU shouldn't always leave latency sensitive tasks to the CPU. Often it's faster to use a dumb brute-force approach to get the job done without a round-trip to the CPU. But imagine a latency-optimized GPU which doesn't have to waste computing resources so it becomes even faster.

Both are heading for the same thing.

>>to be hugely latency-sensitive or high-throughput, there's no telling what application(s) you'll run tomorrow.
>
>Unless, of course, for some reason, you know what applications you'll run tomorrow.
>Like if it's your job or something.
>Like, for example, you are evaluating the choices of what to run right now, so as to buy the necessary software.
>Or maybe you bought the software and have no funds left for more software, so you
>will have to continue using the same software.
>Or maybe they're the same apps you're running right now, and that you've been running for the past ten years.
>You overestimate the uncertainty.

I don't overestimate it. You're absolutely right that systems are always bought with certain uses in mind, and usually it closely matches the actual uses. But that doesn't mean we should underestimate it either. Someone with a 500 € budget may not expect to be able to simulate the ocean currents, but he does expect to be able to run the vast majority of desktop applications, including some that have yet to appear.

In particular, someone who currently opts for a CPU+IGP, would be better off with a homogeneous CPU with gather/scatter in the not too distant future.

>>>Ray-traced Super Mario sounds pretty awesome. I'd get it.
>>
>>Well, actually, due to the wildly varying latencies occuring in ray-tracing, you
>>need an architecture capable of coping with that optimally. A homogenous CPU with
>>gather/scatter can handle fine-grained dynamic balancing of the complex mix of workloads.
>
>There's not really a problem here with varying latencies. Ray tracing on GPUs works fine.

This should sober you up: http://www.youtube.com/watch?v=4bITAdWvMXE

The GPU has lots of limitations and doesn't achieve the same quality as a CPU does in a fixed amount of time. You may note that his 'solution' around 7:30 is a heterogenous architecture, but that's just the current status quo. It fails to take into account that the CPU's vector units got wider, and we still have FMA and gather/scatter to come.

In fact there are reasonably successful 'hybrid' ray-tracers but unsurprisingly the developer's biggest complaint is the communication overhead between the CPU and GPU. A CPU with FMA and gather/scatter offers the best of both world without such overhead. You could also make the GPU more latency optimized but that's a lot more work and you still don't get the unification benefit. So the CPU is going to eventually win this debate.

>>The casual gaming market is booming, and the potential of WebGL and Molehill is
>hard to overestimate. The web allows to reach a whole new market of people, who
>are hesitant to set foot in a game store or install Steam.
>>Mark my words; the next World of Warcraft hype may very well be an HTML5 or Flash game.
>>The emerging Smart TV market also consists of devices with weak graphics chips (shameless plug: http://gametree.tv/platform/).
>
>The casual gaming market is booming, but I suspect the casual gaming market has little to do with hardware at all.
>Casual gamers couldn't care less whether they have a 4-core or a 6-core.

Then why would Intel even manufacture a mainstream quad-core CPU with an IGP?

The thing is, casual gamers aren't just casual gamers. They buy a 'multimedia' system and expect a wide variety of applications to run smoothly. And with lots of software development turning toward multi-core, it's no luxury to put more than two CPU cores into a system, and beyond, to make it sufficiently future-proof.

>Also, Farmville may be comparable in size to WOW, but I doubt many WOW players
>are quitting to play Farmville instead. (Unfortunately, I have no statistics on this.)
>They will continue to play WOW for quite some time. And when they eventually stop
>it will be to play another WOW-like game, probably with better graphics.

I'm not talking about Farmville. I'm talking about actual MMORPGs that are as challenging as World of Warcraft.

>I don't play WOW myself, but the impression I get is that right now, you can't
>really play it on any IGP, except maybe the Bobcat IGP or the Sandy Bridge IGP.

It's not a demanding game by any means. The models have a low polygon count and the lighting is very basic. In fact much of its popularity is due to running well on low-end systems. And it's not like you even need 60 FPS.

It even runs fine with SwiftShader on any quad-core CPU. With AVX, FMA and gather/scatter I'm sure even a dual-core would suffice.

>So, if you want to catch the WOW-player market, you can't aim at matching IGPs,
>you have to aim at matching low-end discrete GPUs.
>And assuming a WOW-successor will eventually appear, your GPU performance target is a moving target.

Sure, but it's a slow moving target. CPUs become much faster in the meantime.

>>Don't get me wrong, there will still be lots of people
>>enjoying games like Crysis 2 (me included), but they need a discrete GPU and a powerful CPU without an IGP.
>
>The Crysis 2 developers have already stated they are aiming somewhat lower hardware-wise
>this time. So if you are expecting Crysis 2 to stress your GPU... it won't.
>So maybe all that these people need is a CPU similar to the ones they have now, and an IGP 4 times faster than today's.

As I've indicated before you can't have a 4 times faster IGP without also scaling the memory bandwidth accordingly. That won't happen unless they put a lot more pins under the chip, making it far more expensive. Low-latency DDR bandwidth is a lot more expensive than GDDR bandwidth. So you shouldn't expect CPU bandwidth to go up very fast, meaning IGPs remain in the low-end segment.

Even if they pulled out all the stops to make it happen, it would be a big shame if such an expensive chip (we're talking current server market segment here) is mediocre at running Crysis 2 but gets beaten by a cheap multi-core CPU at every other application. There's just no demand for such an abomination.

>>>I think this is a big part of why so few games are being made for high-end pcs.
>>>The art cost of better graphics hasn't scaled well.
>>>Performance won't solve this problem.
>>
>>Actually that's not entirely true. Currently artists are responsible for working
>>around many of the limitations of the classic rasterization pipeline. Want realistic
>>foilage?
>
>It's "foliage" not "foilage."

Thanks for the correction!

>>Please produce 3-4 sets of geometry.
>
>It's one mesh per leaf, for each of multiple non-identical leaves per kind of tree, for each of several kinds of tree.
>You can't have a pine tree, a maple tree, and an oak tree in your game unless someone
>tells the computer what a pine tree, a maple tree, and an oak tree each look like.
>And this has to be done by people, because they are the ones who know this stuff.
>And it has to be done separately for each kind of tree. There's no shortcut.
>There's nothing hardware can do to help, other than to get out of the way as much as possible.
>so if it was in the way before and now it's not, that's an improvement. But there's
>no further improvement to be made from there.

I was actually referring to the LOD set. You can manually create the geometry for each LOD, or you could have advanced software assist your. Or, with ray-tracing you don't need an LOD set. But you need a high-throughput low-latency device for that.

>>Want realistic fight animations? Please
>>motion capture every possible move.
>
>A faster cpu wouldn't eliminate the need to motion capture every move. It still has to be done.

Not if you can simulate the muscles and use artificial intelligence to keep the balance. This is in fact how they found out how certain dinosaurs moved/walked/ran.

It's also possible to have realistic looking actors by motion capturing just a few characteristic facial expressions and using advanced models to combine and interpolate them. You need the fine control of a CPU to do that.

And again I'm just scraping the surface. The software market is humongous and I can't possibly know everything developers will concoct when they get access to high-throughput CPUs. The potential is huge though, while there's no demand for IGPs to do anything other than graphics.

>>Want realistic lighting? Please produce multiple
>>sets of radiosity lightmaps.
>
>This one is solveable. Want realistic lighting? Ditch the lightmaps and just
>run the full radiosity algorithm as your game's main renderer. Problem solved.

The "full" radiosity algorithm is too complex for brute-force processing. You need to take clever shortcuts with lots of interactions; i.e. no massive independent data parallelism the GPU prefers to chew on.

>> Want a huge gaming world? Please place portals and occluders...
>
>Some games do just fine with brute-force coherent worldspaces, so occluders and portals were never really needed.
>But the portals are still necessary if the game-world includes non-euclidean spaces. There's no shortcut there.

With a powerful CPU you can get advanced visibility pre-processing in acceptable time so the artist doesn't have to do things manually.

>>Higher (generic) computing performance does help these things. You can do more
>>things procedurally, you can have advanced rigid and soft body physics, you can
>>speed up offline preprocessing, you can compute visibility in real-time, etc. It
>>allows the artists to concentrate more on the actual content.
>
>But if the artist was already concentrating 97% on the actual content, then there is only a ~3% improvement possible.
>Content hasn't gotten much easier, but gamers' expectations have grown at a much faster rate.

That's a big "if". Last time I've heard, artists can use all the automation they can get to speed up the process. We've already come a long way since positioning every vertex manually and painting every texel individually...

Cheers,

Nicolas