By: Nicolas Capens (nicolas.capens.delete@this.gmail.com), February 22, 2011 2:33 am
Room: Moderated Discussions
Hi Seni,
Seni (seniike@hotmail.com) on 2/18/11 wrote:
---------------------------
>>>The IGP's share of the other costs (fab buildout, etc.) is not entirely clear.
>>>
>>>The fabs are the #1 cost. But how much of that cost can be spread out per chip
>>>depends on how many customers you can find to buy one chip each.
>>>If there are lots of customers, smaller chip are gonna cost less.
>>>If there are few customers, you can only utilize the fab fully by making big chips,
>>>in which case the extra area per chip has no effect on fab costs.
>>>If you have multiple generations of fabs at once, then the cost of idling a fab is more complicated.
>>>An increase in the area of one product at a new fab may cause another product to
>>>be shifted to an older fab that would have been idling.
>>>
>>>So, for example, by moving Sandy Bridge's IGP on chip, they consume 32nm capacity
>>>at a greater rate and free up some 45nm capacity.
>>>They then use up the extra 45nm capacity by delaying the 32nm shrink of Atom.
>>>Would it be any cheaper if they made IGPs on 45nm and both Atoms and non-IGP Sandy Bridges on 32nm? Hard to say.
>>>And if they did that, but replaced the 45nm IGP with software and idled the 45nm fabs?
>>
>>I don't see how any of this is relevant. Either you have an IGP at 32 nm, or two
>>more CPU cores at 32 nm. The fab cost is the same.
>
>You proposed two designs: one with 6 cores and one with 4.
>The 6-core supposedly would be the same die area as the 4+IGP, and hence similar cost.
>The 4-core was supposed to be cheaper, but by how much? This is what I was talking about here.
>I argue that the cost of the chip is not proportional to die area, and that the savings is quite likely very small.
>Now that I point that out, you suddenly pretend that the you never proposed the 4-core design.
What I proposed is that you either replace the IGP with two cores, or get rid of it entirely. The 6-core design is slightly cheaper due to R&D and production savings and all that, while the 4-core design also saves proportional die area on top of that.
By reducing the die area you can get more functional dies out of a wafer. Not just because you can fit more dies onto it, but also due to yields (a lesser percentage of defective dies).
So seriously, the IGP does not cost just 5 $.
>>>The IGP's cost of design, v&v, drivers, and so on is shared between current IGPs
>>>and any future products that use the same IGP (e.g. future Atom),
>>>and to some extent future products with next-generation IGPs based on modified
>>>versions of the current IGP. (e.g. Ivy Bridge)
>>
>>That applies to CPU cores between generations as well. But within one generation,
>>having more cores is a negligible R&D cost while having both CPU cores and an IGP is a higher cost.
>
>There is no savings whatsoever to be had by shutting down the IGP R&D program,
>unless you do it completely, across the entire product line.
I do think that in time it's possible to shut down the entire R&D program. Ivy Bridge will have a DX11 IGP so that leaves plenty of architectures to shrink down for Atom till it too can switch to software rendering (as I noted before, ironically it does software vertex processing today). In fact Atom doesn't have the out-of-order execution overhead so equipped with AVX, FMA and gather/scatter it would be more throughput oriented than desktop CPUs!
>Besides, saving money by shutting down R&D programs on a product line where they
>have ~50% market share of a huge market? This is your plan?
Intel's bottom line does not depend on its IGP market share. You think they're sad they no longer sell ISA bus sound cards? Of course not. Sound and soon graphics are just applications which can be run on the CPU so they drive CPU sales.
A 6-core homogenous CPU is more interesting than a 4-core CPU+IGP because it's a more powerful CPU that can still do graphics, while a 4-core homogenous CPU without IGP is considerably cheaper while still offering adequate graphics. Both are a better answer to the needs of people who only occasionally play games (again, no serious gamer would choose an IGP), and it's a better answer to the needs of serious gamers who have no need for an IGP in the first place. So despite losing graphics market share in the strict sense, total sales would go up.
>>No, not at all. Programmability does not mean the end of APIs. Look at OpenCL for
>>CPUs, and the many other choices of APIs and programming languages application developers
>>get to choose from. But while some will pick a high-level API or even a full-fledged
>>engine to create their applications, some will create totally new possibilities.
>>So the software ecosystem expands instead of starting over.
>
>So your plan is to have exposed software rendering competing with driver-based software rendering DirectX and OpenGL.
Yes. Application specific implementations, commercial middleware, open-source frameworks, runtime libraries, operating system APIs, IHV drivers, the lot.
Currently developers are still severely limited by having just one graphics API (seriously, Direct3D and OpenGL are one and the same - I'm part of the Google ANGLE development team), and what the hardware can actually do. OpenCL and CUDA are just a glimpse of what is to come; low-level access to fully generically programmable high-throughput hardware. For the low-end market, CPUs with FMA and gather/scatter can play that role.
Note that a dedicated software renderer can be much faster than one implementing D3D or OGL. For instance lots of games to date use software based visibility determination. Integrating this more closely with the rendering process would result in superior performance.
>>Also note that software rendering would enable both backward compatibility AND
>>forward compatibility. Running a game which demands DirectX 12 would require merely a software upgrade.
>
>A software upgrade of what software? The OS? The drivers? The game?
Anything. I've played Half-Life 2 (Direct3D 9.0) on a laptop with an ATI Rage LT Pro (Direct3D 6.0) by dropping in SwiftShader. It would have worked just the same if it came with the game or was part of the O.S. or a driver.
SwiftShader has been licensed for individual applications, but it has also been licensed for an API like Adobe Molehill (meaning every 3D Flash application can use it). So it depends on the situation what makes most sense, but software rendering clearly leaves all options open.
>>>Each sampler does a 4-texel quad at a time, so 2 of them do 8 texels per cycle.
>>
>>Why would samplers process a quad at a time? Do you have any proof of that?
>
>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.
>>I was wrong about the 2 samplers though, it's actually 4 (32-bit textels): http://www.techarp.com/showarticle.aspx?artno=88&pgno=23
>
>I seem to have been wrong about some of the numbers. I took your word for it that
>there were 2 samplers, but it looks like there is actually only one, so it's only 4 texels/clock.
>Which is staggeringly poor. An original Geforce from 11 years ago could do 8 per clock (at like 150MHz though).
The ALU:TEX ratio in shaders is much higher than in the early GeForce years. So the higher frequency is sufficient to keep up with the texturing needs of modern games. 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).
>>Still, 5.4 GT/s peak isn't a whole lot, especially considering that the IGP will
>>be arithmetic limited much of the time.
>
>I doubt it. Those texturing numbers look terrible.
>High end GPUs do 64+ texels per clock. This does 4 per clock.
>Unless you feed it characteristically different workloads than what high-end GPUS
>see, it's mostly going to be texture-limited, except when it's bandwidth-limited.
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.
A GeForce GTX 580 can do 49.41 GT/s, but it also has an order of magnitude higher GFLOPS and an order of magnitude higher bandwidth. So the IGP is very weak in comparison but the texturing capabilities are actually quite proportional.
The reason GPUs have such insane texture sampling capabilities, is because specific shaders are more texture heavy. For instance a full screen effect performing a blur operation could have a 1:1 TEX:ALU ratio. Even if just one in ten shaders are like that, you need to prevent them from dominating the frame time. So to avoid such bottlenecks the samplers are overdimensioned.
A CPU with gather/scatter wouldn't suffer from that. Either it's used for texture sampling, or gather/scatter can be used for the lookup tables to evaluate transcendental functions, or heavy vertex attribute fetching, or parallel rasterization, or pretty much every other task requiring memory accesses!
>>>If you beef up the gather unit so it can pull multiple source texels from a single
>>>L1 cache access in a single cycle, you could catch up a little.
>>>But this would require a swarm of enormous multiplexers in the middle of the L1D/LSU
>>>datapath, which would probably add 2 or 3 cycles to L1 latency and would devastating to all non-graphics code.
>>
>>It wouldn't be all that costly. There's already a 512-bit to 128-bit 'shift' networks
>>with byte granularity in place for each of SNB's load units. Turning this into a
>
>But there's only one of it. You would need 4 or 8 of them to do fast gathers.
No, SNB has two 128-bit load units per core.
>>network capable of selecting 4 x 32-bit ins't that much more complicated.
>
>Shouldn't that be 8x32?
4 x 32-bit per load unit suffices for a maximum of 256-bit gather per cycle.
>>It's somewhat comparable to the multiplexers already in the execution units to
>>support all the permutation type instructions. Note also that these have a latency
>>of 1 cycle. So both in terms of area and timings supporting gather/scatter shouldn't be a big hurdle.
>>
>
>But again, there's only one or two of these in the execution units. You would need a lot of them.
Selecting four elements per cache line instead of one is relatively simple. Note that CPUs have been able to extract data from cache lines since the dawn of caches (more than two decades ago for consumer CPUs). So asking for four accesses per LSU on a future process isn't really pushing it.
>>>Also, it's not clear that other supporting parts of the chip could keep up, in
>>>particular, the parts of the LSU and TLB associated with enforcing memory ordering,
>>>coherency, memory protection checks and so on.
>>
>>It's only accessing one cache line per clock (per LSU).
>
>This stuff isn't done per cache line. It's done per access.
It's done per cache line being accessed. If today you have a variable straddling two cache lines, one part could be in L1 cache while the other part could be swapped out to disk. They're loaded sequentially, not simultaneously, and thus it doesn't require any additional ports to the TLB and such. Neither does gather/scatter put any more stress on the per cache line operations.
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.
>>So there's no extra pressure
>>on any of those parts. It merely needs to be able to collect four elements out of
>>a chace line, which isn't all that hard. And computing which elements are stored
>>within the same cache line is easy too. You don't even need the full address per
>>element for that. Just compare the upper 25 bits of the offsets and compute the
>>lower 7 bits of the address to determine the position within the cache line (and 'overflows').
>
>This is not a 32 bit processor, so addresses aren't 25+7. They are 57+7.
>To check to which elements are stored in the same cache line, you just have to
>run ALL POSSIBLE PAIRS in parallel through separate 57-bit comparators.
>So, for 8 lookups per AVX word, that's 36 comparators.
>
>With all 8 57-bit numbers running as a single 456-bit bus, and then each comparator
>running out taps to the 114 input bits it needs, I get 456 bits wide and 114*36= 4104 bits tall.
>This is a big thing. And that's just the wiring feeding into the comparators.
>
>Maybe it's not as easy as you thought?
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?
You don't need to add each of the 32-bit offsets to the 64-bit base address to determine that. I can tell right away that the elements are stored more than a cache line width apart by comparing the upper 25 bits of the offset.
Are offsets 0x0000003F and 0x00000040 located on the same cache line? That actually depends on the sum of the lower 7 bits of the offsets and the base address.
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.
So all you need per LSU is four 25-bit comparators and four 7-bit adders. And since you have an entire cycle to determine whether any other cache lines need to be fetched, these comparators and adders (which are already very narrow) can use a particularly compact implementation with low power consumption.
>>>So basically, what we're looking at is that gather/scatter alone needs to make
>>>the cores 4 times faster to hit your target of two cores=1 IGP.
>>
>>Not really. 5.4 GT/s corresponds to 86.4 GB/s bandwidth to the texture cache. With
>>two 128-bit gather units a 3.4 GHz CPU would have 108.8 GB/s bandwidth to L1 cache,
>>per core! So even if you reduce the clock speed to keep the power consumption in
>>check, 6 cores amply exceed the minimal bandwidth required to match the IGP performance.
>>
>
>Only because the IGP is worse than I thought.
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."
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.
>>>The point is there is are two separate the market segments here served by separate product lines.
>>>Gulftown is high-core-count, high TDP, no IGP product, appropriate for mainly for
>>>certain uses. (High-end Desktops, Servers...)
>>>Sandy Bridge is a moderate-core-count, moderate TDP, CPU+IGP product, appropriate
>>>for other different uses. (DTR Laptops, IGP Laptops...)
>>
>>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.
>>An operation is an operation. You need the same ones for any market segment. HPC
>>and desktop applications alike are written in C-like languages which use generic
>>integer and floating-point operations, memory accesses, control flow, etc. So there's
>>little point diversifying for other market segments, other than performance. Server
>>chips could be made more power efficient by having more cores and clocking them
>>lower, but it can essentially be the same architecture.
>
>I don't think you can just claim "All code is the same."
>Granted, Turing completeness and all, differences are limited to such things as
>speed and power efficiency. But the differences here can be huge.
Again, most applications are a complex mix of workloads. But even if some tend to be hugely latency-sensitive or high-throughput, there's no telling what application(s) you'll run tomorrow.
Besides, the IGP is only tolerably good at graphics. Don't even think about letting it perform any other task. To make it capable of some worthwhile GPGPU processing, it needs to become far more programmable and have a memory subsystem capable of handling arbitrary data flows. Basically you need to turn it into something much more CPU-like. So you might as well relieve the poor thing of it's suffering and give the CPU cores gather/scatter support.
>>>There is just too much room for further improvement in graphics quality in games.
>>
>>It goes in multiple directions. Serious gamers will never have enough graphics
>power. But casual gamers won't pay extra to play a ray-traced Super Mario.
>
>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.
>>> So seriously, the group of people for which low-end graphics suffices, is growing.
>
>But is the group for which it does not suffice shrinking? Or are they both growing together?
I don't have exact numbers at the moment, but I'm under the impression that the percentage of people buying high-end graphics cards is slowly shrinking. There isn't a single game on the market today which I can't fully enjoy on my GTX 460. Even Crysis 2 won't compel me to upgrade, and is likely going to be the most demanding game for some years to come.
As a matter of fact AMD decided to produce smaller sized GPUs, to better match the market demand. The high-end solutions consists of dual-GPU cards (and CrossFire). NVIDIA's tactic is to continue producing large GPUs but to also sell them as HPC solutions. If there was a high demand for high-end graphics, they'd probably have separate architectures for both markets.
They need these high-end products to create a halo effect and satisfy the bragging needs of loud enthusiasts, but what the average consumer actually buys are the mid-end and low-end products.
>>Whereas previously IGPs were considered insufferable, they're now considered adequate for a very sizable market segment. The statistics don't lie: http://unity3d.com/webplayer/hwstats/pages/web-2011Q1-gfxcard.html
>
>How representative is unity3d webplayer?
>Last I checked, the stats from Steam hardware survey show a quite different picture.
>Not that Steam is representative either...
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/).
Unity3D already walks the line between casual gaming and more serious entertainment. So yes I think its statistics are fairly representative of the hardware profile of the future gaming market. 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 wildcard here is the stalled console cycle. This hasn't happened before since
>>>the 1970s, IIRC, so it's unclear what effect it will have.
>>>If pc games continue to be mostly console ports, even when there is no new console
>>>for 7+ years in a row, it could create a temporary plateau effect.
>>>There might be no popular game demanding enough to need more than an IGP, thus killing the GPU market altogether.
>>
>>Exactly. What we need is innovation. A homogenous CPU with FMA and gather/scatter
>>would give developers the freedom to develop some new exciting applications that were previously unthinkable.
>
>I'm not so sure about this.
>Mostly what we've gained since the NES is better graphics, but you can't have better
>graphics unless you hire more/better artists, and that costs a lot of money.
>
>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? Please produce 3-4 sets of geometry. Want realistic fight animations? Please motion capture every possible move. Want realistic lighting? Please produce multiple sets of radiosity lightmaps. Want a huge gaming world? Please place portals and occluders...
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. These things have been proposed as GPGPU tasks as well, but I have yet to see really succesful implementations.
The thing is, it takes years to develop fixed-function hardware, while it only takes days to do something in software. For example unifying the vertex and pixel pipeline so you can sample textures in a vertex shader took probably four years from concept to products on the shelves. With a software renderer it takes less than a day to call the texture sampling function from within the vertex processing routine, and a couple days later it can be sent to a client who issues a patch and lets every customer enjoy more exciting gaphics. Granted, that's an old example, but it should illustrate that the possibilities are endless.
Programmable shaders triggered a revolution in computer graphics. But we've far from reached an endpoint.
Cheers,
Nicolas
Seni (seniike@hotmail.com) on 2/18/11 wrote:
---------------------------
>>>The IGP's share of the other costs (fab buildout, etc.) is not entirely clear.
>>>
>>>The fabs are the #1 cost. But how much of that cost can be spread out per chip
>>>depends on how many customers you can find to buy one chip each.
>>>If there are lots of customers, smaller chip are gonna cost less.
>>>If there are few customers, you can only utilize the fab fully by making big chips,
>>>in which case the extra area per chip has no effect on fab costs.
>>>If you have multiple generations of fabs at once, then the cost of idling a fab is more complicated.
>>>An increase in the area of one product at a new fab may cause another product to
>>>be shifted to an older fab that would have been idling.
>>>
>>>So, for example, by moving Sandy Bridge's IGP on chip, they consume 32nm capacity
>>>at a greater rate and free up some 45nm capacity.
>>>They then use up the extra 45nm capacity by delaying the 32nm shrink of Atom.
>>>Would it be any cheaper if they made IGPs on 45nm and both Atoms and non-IGP Sandy Bridges on 32nm? Hard to say.
>>>And if they did that, but replaced the 45nm IGP with software and idled the 45nm fabs?
>>
>>I don't see how any of this is relevant. Either you have an IGP at 32 nm, or two
>>more CPU cores at 32 nm. The fab cost is the same.
>
>You proposed two designs: one with 6 cores and one with 4.
>The 6-core supposedly would be the same die area as the 4+IGP, and hence similar cost.
>The 4-core was supposed to be cheaper, but by how much? This is what I was talking about here.
>I argue that the cost of the chip is not proportional to die area, and that the savings is quite likely very small.
>Now that I point that out, you suddenly pretend that the you never proposed the 4-core design.
What I proposed is that you either replace the IGP with two cores, or get rid of it entirely. The 6-core design is slightly cheaper due to R&D and production savings and all that, while the 4-core design also saves proportional die area on top of that.
By reducing the die area you can get more functional dies out of a wafer. Not just because you can fit more dies onto it, but also due to yields (a lesser percentage of defective dies).
So seriously, the IGP does not cost just 5 $.
>>>The IGP's cost of design, v&v, drivers, and so on is shared between current IGPs
>>>and any future products that use the same IGP (e.g. future Atom),
>>>and to some extent future products with next-generation IGPs based on modified
>>>versions of the current IGP. (e.g. Ivy Bridge)
>>
>>That applies to CPU cores between generations as well. But within one generation,
>>having more cores is a negligible R&D cost while having both CPU cores and an IGP is a higher cost.
>
>There is no savings whatsoever to be had by shutting down the IGP R&D program,
>unless you do it completely, across the entire product line.
I do think that in time it's possible to shut down the entire R&D program. Ivy Bridge will have a DX11 IGP so that leaves plenty of architectures to shrink down for Atom till it too can switch to software rendering (as I noted before, ironically it does software vertex processing today). In fact Atom doesn't have the out-of-order execution overhead so equipped with AVX, FMA and gather/scatter it would be more throughput oriented than desktop CPUs!
>Besides, saving money by shutting down R&D programs on a product line where they
>have ~50% market share of a huge market? This is your plan?
Intel's bottom line does not depend on its IGP market share. You think they're sad they no longer sell ISA bus sound cards? Of course not. Sound and soon graphics are just applications which can be run on the CPU so they drive CPU sales.
A 6-core homogenous CPU is more interesting than a 4-core CPU+IGP because it's a more powerful CPU that can still do graphics, while a 4-core homogenous CPU without IGP is considerably cheaper while still offering adequate graphics. Both are a better answer to the needs of people who only occasionally play games (again, no serious gamer would choose an IGP), and it's a better answer to the needs of serious gamers who have no need for an IGP in the first place. So despite losing graphics market share in the strict sense, total sales would go up.
>>No, not at all. Programmability does not mean the end of APIs. Look at OpenCL for
>>CPUs, and the many other choices of APIs and programming languages application developers
>>get to choose from. But while some will pick a high-level API or even a full-fledged
>>engine to create their applications, some will create totally new possibilities.
>>So the software ecosystem expands instead of starting over.
>
>So your plan is to have exposed software rendering competing with driver-based software rendering DirectX and OpenGL.
Yes. Application specific implementations, commercial middleware, open-source frameworks, runtime libraries, operating system APIs, IHV drivers, the lot.
Currently developers are still severely limited by having just one graphics API (seriously, Direct3D and OpenGL are one and the same - I'm part of the Google ANGLE development team), and what the hardware can actually do. OpenCL and CUDA are just a glimpse of what is to come; low-level access to fully generically programmable high-throughput hardware. For the low-end market, CPUs with FMA and gather/scatter can play that role.
Note that a dedicated software renderer can be much faster than one implementing D3D or OGL. For instance lots of games to date use software based visibility determination. Integrating this more closely with the rendering process would result in superior performance.
>>Also note that software rendering would enable both backward compatibility AND
>>forward compatibility. Running a game which demands DirectX 12 would require merely a software upgrade.
>
>A software upgrade of what software? The OS? The drivers? The game?
Anything. I've played Half-Life 2 (Direct3D 9.0) on a laptop with an ATI Rage LT Pro (Direct3D 6.0) by dropping in SwiftShader. It would have worked just the same if it came with the game or was part of the O.S. or a driver.
SwiftShader has been licensed for individual applications, but it has also been licensed for an API like Adobe Molehill (meaning every 3D Flash application can use it). So it depends on the situation what makes most sense, but software rendering clearly leaves all options open.
>>>Each sampler does a 4-texel quad at a time, so 2 of them do 8 texels per cycle.
>>
>>Why would samplers process a quad at a time? Do you have any proof of that?
>
>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.
>>I was wrong about the 2 samplers though, it's actually 4 (32-bit textels): http://www.techarp.com/showarticle.aspx?artno=88&pgno=23
>
>I seem to have been wrong about some of the numbers. I took your word for it that
>there were 2 samplers, but it looks like there is actually only one, so it's only 4 texels/clock.
>Which is staggeringly poor. An original Geforce from 11 years ago could do 8 per clock (at like 150MHz though).
The ALU:TEX ratio in shaders is much higher than in the early GeForce years. So the higher frequency is sufficient to keep up with the texturing needs of modern games. 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).
>>Still, 5.4 GT/s peak isn't a whole lot, especially considering that the IGP will
>>be arithmetic limited much of the time.
>
>I doubt it. Those texturing numbers look terrible.
>High end GPUs do 64+ texels per clock. This does 4 per clock.
>Unless you feed it characteristically different workloads than what high-end GPUS
>see, it's mostly going to be texture-limited, except when it's bandwidth-limited.
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.
A GeForce GTX 580 can do 49.41 GT/s, but it also has an order of magnitude higher GFLOPS and an order of magnitude higher bandwidth. So the IGP is very weak in comparison but the texturing capabilities are actually quite proportional.
The reason GPUs have such insane texture sampling capabilities, is because specific shaders are more texture heavy. For instance a full screen effect performing a blur operation could have a 1:1 TEX:ALU ratio. Even if just one in ten shaders are like that, you need to prevent them from dominating the frame time. So to avoid such bottlenecks the samplers are overdimensioned.
A CPU with gather/scatter wouldn't suffer from that. Either it's used for texture sampling, or gather/scatter can be used for the lookup tables to evaluate transcendental functions, or heavy vertex attribute fetching, or parallel rasterization, or pretty much every other task requiring memory accesses!
>>>If you beef up the gather unit so it can pull multiple source texels from a single
>>>L1 cache access in a single cycle, you could catch up a little.
>>>But this would require a swarm of enormous multiplexers in the middle of the L1D/LSU
>>>datapath, which would probably add 2 or 3 cycles to L1 latency and would devastating to all non-graphics code.
>>
>>It wouldn't be all that costly. There's already a 512-bit to 128-bit 'shift' networks
>>with byte granularity in place for each of SNB's load units. Turning this into a
>
>But there's only one of it. You would need 4 or 8 of them to do fast gathers.
No, SNB has two 128-bit load units per core.
>>network capable of selecting 4 x 32-bit ins't that much more complicated.
>
>Shouldn't that be 8x32?
4 x 32-bit per load unit suffices for a maximum of 256-bit gather per cycle.
>>It's somewhat comparable to the multiplexers already in the execution units to
>>support all the permutation type instructions. Note also that these have a latency
>>of 1 cycle. So both in terms of area and timings supporting gather/scatter shouldn't be a big hurdle.
>>
>
>But again, there's only one or two of these in the execution units. You would need a lot of them.
Selecting four elements per cache line instead of one is relatively simple. Note that CPUs have been able to extract data from cache lines since the dawn of caches (more than two decades ago for consumer CPUs). So asking for four accesses per LSU on a future process isn't really pushing it.
>>>Also, it's not clear that other supporting parts of the chip could keep up, in
>>>particular, the parts of the LSU and TLB associated with enforcing memory ordering,
>>>coherency, memory protection checks and so on.
>>
>>It's only accessing one cache line per clock (per LSU).
>
>This stuff isn't done per cache line. It's done per access.
It's done per cache line being accessed. If today you have a variable straddling two cache lines, one part could be in L1 cache while the other part could be swapped out to disk. They're loaded sequentially, not simultaneously, and thus it doesn't require any additional ports to the TLB and such. Neither does gather/scatter put any more stress on the per cache line operations.
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.
>>So there's no extra pressure
>>on any of those parts. It merely needs to be able to collect four elements out of
>>a chace line, which isn't all that hard. And computing which elements are stored
>>within the same cache line is easy too. You don't even need the full address per
>>element for that. Just compare the upper 25 bits of the offsets and compute the
>>lower 7 bits of the address to determine the position within the cache line (and 'overflows').
>
>This is not a 32 bit processor, so addresses aren't 25+7. They are 57+7.
>To check to which elements are stored in the same cache line, you just have to
>run ALL POSSIBLE PAIRS in parallel through separate 57-bit comparators.
>So, for 8 lookups per AVX word, that's 36 comparators.
>
>With all 8 57-bit numbers running as a single 456-bit bus, and then each comparator
>running out taps to the 114 input bits it needs, I get 456 bits wide and 114*36= 4104 bits tall.
>This is a big thing. And that's just the wiring feeding into the comparators.
>
>Maybe it's not as easy as you thought?
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?
You don't need to add each of the 32-bit offsets to the 64-bit base address to determine that. I can tell right away that the elements are stored more than a cache line width apart by comparing the upper 25 bits of the offset.
Are offsets 0x0000003F and 0x00000040 located on the same cache line? That actually depends on the sum of the lower 7 bits of the offsets and the base address.
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.
So all you need per LSU is four 25-bit comparators and four 7-bit adders. And since you have an entire cycle to determine whether any other cache lines need to be fetched, these comparators and adders (which are already very narrow) can use a particularly compact implementation with low power consumption.
>>>So basically, what we're looking at is that gather/scatter alone needs to make
>>>the cores 4 times faster to hit your target of two cores=1 IGP.
>>
>>Not really. 5.4 GT/s corresponds to 86.4 GB/s bandwidth to the texture cache. With
>>two 128-bit gather units a 3.4 GHz CPU would have 108.8 GB/s bandwidth to L1 cache,
>>per core! So even if you reduce the clock speed to keep the power consumption in
>>check, 6 cores amply exceed the minimal bandwidth required to match the IGP performance.
>>
>
>Only because the IGP is worse than I thought.
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."
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.
>>>The point is there is are two separate the market segments here served by separate product lines.
>>>Gulftown is high-core-count, high TDP, no IGP product, appropriate for mainly for
>>>certain uses. (High-end Desktops, Servers...)
>>>Sandy Bridge is a moderate-core-count, moderate TDP, CPU+IGP product, appropriate
>>>for other different uses. (DTR Laptops, IGP Laptops...)
>>
>>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.
>>An operation is an operation. You need the same ones for any market segment. HPC
>>and desktop applications alike are written in C-like languages which use generic
>>integer and floating-point operations, memory accesses, control flow, etc. So there's
>>little point diversifying for other market segments, other than performance. Server
>>chips could be made more power efficient by having more cores and clocking them
>>lower, but it can essentially be the same architecture.
>
>I don't think you can just claim "All code is the same."
>Granted, Turing completeness and all, differences are limited to such things as
>speed and power efficiency. But the differences here can be huge.
Again, most applications are a complex mix of workloads. But even if some tend to be hugely latency-sensitive or high-throughput, there's no telling what application(s) you'll run tomorrow.
Besides, the IGP is only tolerably good at graphics. Don't even think about letting it perform any other task. To make it capable of some worthwhile GPGPU processing, it needs to become far more programmable and have a memory subsystem capable of handling arbitrary data flows. Basically you need to turn it into something much more CPU-like. So you might as well relieve the poor thing of it's suffering and give the CPU cores gather/scatter support.
>>>There is just too much room for further improvement in graphics quality in games.
>>
>>It goes in multiple directions. Serious gamers will never have enough graphics
>power. But casual gamers won't pay extra to play a ray-traced Super Mario.
>
>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.
>>> So seriously, the group of people for which low-end graphics suffices, is growing.
>
>But is the group for which it does not suffice shrinking? Or are they both growing together?
I don't have exact numbers at the moment, but I'm under the impression that the percentage of people buying high-end graphics cards is slowly shrinking. There isn't a single game on the market today which I can't fully enjoy on my GTX 460. Even Crysis 2 won't compel me to upgrade, and is likely going to be the most demanding game for some years to come.
As a matter of fact AMD decided to produce smaller sized GPUs, to better match the market demand. The high-end solutions consists of dual-GPU cards (and CrossFire). NVIDIA's tactic is to continue producing large GPUs but to also sell them as HPC solutions. If there was a high demand for high-end graphics, they'd probably have separate architectures for both markets.
They need these high-end products to create a halo effect and satisfy the bragging needs of loud enthusiasts, but what the average consumer actually buys are the mid-end and low-end products.
>>Whereas previously IGPs were considered insufferable, they're now considered adequate for a very sizable market segment. The statistics don't lie: http://unity3d.com/webplayer/hwstats/pages/web-2011Q1-gfxcard.html
>
>How representative is unity3d webplayer?
>Last I checked, the stats from Steam hardware survey show a quite different picture.
>Not that Steam is representative either...
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/).
Unity3D already walks the line between casual gaming and more serious entertainment. So yes I think its statistics are fairly representative of the hardware profile of the future gaming market. 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 wildcard here is the stalled console cycle. This hasn't happened before since
>>>the 1970s, IIRC, so it's unclear what effect it will have.
>>>If pc games continue to be mostly console ports, even when there is no new console
>>>for 7+ years in a row, it could create a temporary plateau effect.
>>>There might be no popular game demanding enough to need more than an IGP, thus killing the GPU market altogether.
>>
>>Exactly. What we need is innovation. A homogenous CPU with FMA and gather/scatter
>>would give developers the freedom to develop some new exciting applications that were previously unthinkable.
>
>I'm not so sure about this.
>Mostly what we've gained since the NES is better graphics, but you can't have better
>graphics unless you hire more/better artists, and that costs a lot of money.
>
>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? Please produce 3-4 sets of geometry. Want realistic fight animations? Please motion capture every possible move. Want realistic lighting? Please produce multiple sets of radiosity lightmaps. Want a huge gaming world? Please place portals and occluders...
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. These things have been proposed as GPGPU tasks as well, but I have yet to see really succesful implementations.
The thing is, it takes years to develop fixed-function hardware, while it only takes days to do something in software. For example unifying the vertex and pixel pipeline so you can sample textures in a vertex shader took probably four years from concept to products on the shelves. With a software renderer it takes less than a day to call the texture sampling function from within the vertex processing routine, and a couple days later it can be sent to a client who issues a patch and lets every customer enjoy more exciting gaphics. Granted, that's an old example, but it should illustrate that the possibilities are endless.
Programmable shaders triggered a revolution in computer graphics. But we've far from reached an endpoint.
Cheers,
Nicolas
Topic | Posted By | Date |
---|---|---|
Sandy Bridge CPU article online | David Kanter | 2010/09/26 08:35 PM |
Sandy Bridge CPU article online | Alex | 2010/09/27 04:22 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:06 AM |
Sandy Bridge CPU article online | someone | 2010/09/27 05:03 AM |
Sandy Bridge CPU article online | slacker | 2010/09/27 01:08 PM |
PowerPC is now Power | Paul A. Clayton | 2010/09/27 03:34 PM |
Sandy Bridge CPU article online | Dave | 2010/11/10 09:15 PM |
Sandy Bridge CPU article online | someone | 2010/09/27 05:23 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 05:39 PM |
Optimizing register clear | Paul A. Clayton | 2010/09/28 11:34 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 05:54 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:15 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 10:02 AM |
Sandy Bridge CPU article online | mpx | 2010/09/27 10:44 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 01:37 PM |
Precisely | David Kanter | 2010/09/27 02:22 PM |
Sandy Bridge CPU article online | Richard Cownie | 2010/09/27 07:27 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:01 AM |
Sandy Bridge CPU article online | Richard Cownie | 2010/09/27 09:40 AM |
Sandy Bridge CPU article online | boots | 2010/09/27 10:19 AM |
Right, mid-2011, not 2010. Sorry (NT) | Richard Cownie | 2010/09/27 10:42 AM |
bulldozer single thread performance | Max | 2010/09/27 11:57 AM |
bulldozer single thread performance | Matt Waldhauer | 2011/03/02 10:32 AM |
Sandy Bridge CPU article online | Pun Zu | 2010/09/27 10:32 AM |
Sandy Bridge CPU article online | ? | 2010/09/27 10:44 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 12:11 PM |
My opinion is that anything that would take advantage of 256-bit AVX | redpriest | 2010/09/27 12:17 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/27 02:09 PM |
My opinion is that anything that would take advantage of 256-bit AVX | redpriest | 2010/09/27 03:06 PM |
My opinion is that anything that would take advantage of 256-bit AVX | David Kanter | 2010/09/27 04:23 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 02:57 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:35 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Matt Waldhauer | 2010/09/28 09:58 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/27 05:39 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:14 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Megol | 2010/09/28 01:17 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Michael S | 2010/09/28 04:47 AM |
PGI | Carlie Coats | 2010/09/28 09:23 AM |
gfortran... | Carlie Coats | 2010/09/29 08:33 AM |
My opinion is that anything that would take advantage of 256-bit AVX | mpx | 2010/09/28 11:58 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Michael S | 2010/09/28 12:36 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Foo_ | 2010/09/29 12:08 AM |
My opinion is that anything that would take advantage of 256-bit AVX | mpx | 2010/09/28 10:37 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/28 12:19 PM |
My opinion is that anything that would take advantage of 256-bit AVX | hobold | 2010/09/28 02:08 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:26 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Anthony | 2010/09/28 09:31 PM |
Sandy Bridge CPU article online | Hans de Vries | 2010/09/27 01:19 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 02:19 PM |
Sandy Bridge CPU article online | -Sweeper_ | 2010/09/27 04:50 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 05:41 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/27 01:55 PM |
Sandy Bridge CPU article online | line98 | 2010/09/27 02:05 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 02:20 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/27 02:23 PM |
Sandy Bridge CPU article online | line98 | 2010/09/27 02:42 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 08:33 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 03:04 PM |
Sandy Bridge CPU article online | Jack | 2010/09/27 03:40 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 10:47 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 10:54 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 10:59 PM |
Sandy Bridge CPU article online | JS | 2010/09/28 12:18 AM |
Sandy Bridge CPU article online | Royi | 2010/09/28 12:31 AM |
Sandy Bridge CPU article online | Jack | 2010/09/28 05:34 AM |
Sandy Bridge CPU article online | Royi | 2010/09/28 07:22 AM |
Sandy Bridge CPU article online | Foo_ | 2010/09/28 11:53 AM |
Sandy Bridge CPU article online | Paul | 2010/09/28 12:17 PM |
Sandy Bridge CPU article online | mpx | 2010/09/28 12:22 PM |
Sandy Bridge CPU article online | anonymous | 2010/09/28 01:06 PM |
Sandy Bridge CPU article online | IntelUser2000 | 2010/09/29 12:49 AM |
Sandy Bridge CPU article online | Jack | 2010/09/28 04:08 PM |
Sandy Bridge CPU article online | mpx | 2010/09/29 12:50 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/29 11:01 AM |
Sandy Bridge CPU article online | Royi | 2010/09/29 11:48 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 01:15 PM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/29 01:27 PM |
Sandy Bridge CPU article online | ? | 2010/09/29 10:18 PM |
Sandy Bridge CPU article online | savantu | 2010/09/29 11:28 PM |
Sandy Bridge CPU article online | ? | 2010/09/30 02:43 AM |
Sandy Bridge CPU article online | gallier2 | 2010/09/30 03:18 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 07:38 AM |
Sandy Bridge CPU article online | David Hess | 2010/09/30 09:28 AM |
moderation (again) | hobold | 2010/10/01 04:08 AM |
Sandy Bridge CPU article online | Megol | 2010/09/30 01:13 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 02:47 AM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 07:54 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 09:18 AM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 11:04 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 11:38 AM |
Sandy Bridge CPU article online | Michael S | 2010/09/30 12:02 PM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 07:09 PM |
Sandy Bridge CPU article online | mpx | 2010/09/30 11:40 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 12:00 PM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 07:44 PM |
Sandy Bridge CPU article online | David Hess | 2010/09/30 09:36 AM |
Sandy Bridge CPU article online | someone | 2010/09/30 10:23 AM |
Sandy Bridge CPU article online | mpx | 2010/09/30 12:50 PM |
wii lesson | Michael S | 2010/09/30 01:12 PM |
wii lesson | Dan Downs | 2010/09/30 02:33 PM |
wii lesson | Kevin G | 2010/09/30 11:27 PM |
wii lesson | Rohit | 2010/10/01 06:53 AM |
wii lesson | Kevin G | 2010/10/02 02:30 AM |
wii lesson | mpx | 2010/10/01 08:02 AM |
wii lesson | IntelUser2000 | 2010/10/01 08:31 AM |
GPUs and games | David Kanter | 2010/09/30 07:17 PM |
GPUs and games | hobold | 2010/10/01 04:27 AM |
GPUs and games | anonymous | 2010/10/01 05:35 AM |
GPUs and games | Gabriele Svelto | 2010/10/01 08:07 AM |
GPUs and games | Linus Torvalds | 2010/10/01 09:41 AM |
GPUs and games | Anon | 2010/10/01 10:23 AM |
Can Intel do *this* ??? | Mark Roulo | 2010/10/03 02:17 PM |
Can Intel do *this* ??? | Anon | 2010/10/03 02:29 PM |
Can Intel do *this* ??? | Mark Roulo | 2010/10/03 02:55 PM |
Can Intel do *this* ??? | Anon | 2010/10/03 04:45 PM |
Can Intel do *this* ??? | Ian Ameline | 2010/10/03 09:35 PM |
Graphics, IGPs, and Cache | Joe | 2010/10/10 08:51 AM |
Graphics, IGPs, and Cache | Anon | 2010/10/10 09:18 PM |
Graphics, IGPs, and Cache | Rohit | 2010/10/11 05:14 AM |
Graphics, IGPs, and Cache | hobold | 2010/10/11 05:43 AM |
Maybe the IGPU doesn't load into the L3 | Mark Roulo | 2010/10/11 07:05 AM |
Graphics, IGPs, and Cache | David Kanter | 2010/10/11 08:01 AM |
Can Intel do *this* ??? | Gabriele Svelto | 2010/10/03 11:31 PM |
Kanter's Law. | Ian Ameline | 2010/10/01 01:05 PM |
Kanter's Law. | David Kanter | 2010/10/01 01:18 PM |
Kanter's Law. | Ian Ameline | 2010/10/01 01:33 PM |
Kanter's Law. | Kevin G | 2010/10/01 03:19 PM |
Kanter's Law. | IntelUser2000 | 2010/10/01 09:36 PM |
Kanter's Law. | Kevin G | 2010/10/02 02:15 AM |
Kanter's Law. | IntelUser2000 | 2010/10/02 01:35 PM |
Wii vs pc's | Rohit | 2010/10/01 06:34 PM |
Wii vs pc's | Gabriele Svelto | 2010/10/01 10:54 PM |
GPUs and games | mpx | 2010/10/02 10:30 AM |
GPUs and games | Foo_ | 2010/10/02 03:03 PM |
GPUs and games | mpx | 2010/10/03 10:29 AM |
GPUs and games | Foo_ | 2010/10/03 12:52 PM |
GPUs and games | mpx | 2010/10/03 02:29 PM |
GPUs and games | Anon | 2010/10/03 02:49 PM |
GPUs and games | mpx | 2010/10/04 10:42 AM |
GPUs and games | MS | 2010/10/04 01:51 PM |
GPUs and games | Anon | 2010/10/04 07:29 PM |
persistence of vision | hobold | 2010/10/04 10:47 PM |
GPUs and games | mpx | 2010/10/04 11:51 PM |
GPUs and games | MS | 2010/10/05 05:49 AM |
GPUs and games | Jack | 2010/10/05 10:17 AM |
GPUs and games | MS | 2010/10/05 04:19 PM |
GPUs and games | Jack | 2010/10/05 10:11 AM |
GPUs and games | mpx | 2010/10/05 11:51 AM |
GPUs and games | David Kanter | 2010/10/06 08:04 AM |
GPUs and games | jack | 2010/10/06 08:34 PM |
GPUs and games | Linus Torvalds | 2010/10/05 06:29 AM |
GPUs and games | Foo_ | 2010/10/04 03:49 AM |
GPUs and games | Jeremiah | 2010/10/08 09:58 AM |
GPUs and games | MS | 2010/10/08 12:37 PM |
GPUs and games | Salvatore De Dominicis | 2010/10/04 12:41 AM |
GPUs and games | Kevin G | 2010/10/05 01:13 PM |
GPUs and games | mpx | 2010/10/03 10:36 AM |
GPUs and games | David Kanter | 2010/10/04 06:08 AM |
GPUs and games | Kevin G | 2010/10/04 09:38 AM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 08:19 PM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 11:06 AM |
Sandy Bridge CPU article online | rwessel | 2010/09/30 01:29 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/30 02:06 PM |
Sandy Bridge CPU article online | rwessel | 2010/09/30 05:55 PM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 02:53 AM |
Sandy Bridge CPU article online | rwessel | 2010/10/01 07:30 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 08:31 AM |
Sandy Bridge CPU article online | rwessel | 2010/10/01 09:56 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:28 PM |
Sandy Bridge CPU article online | Ricardo B | 2010/10/02 04:38 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/02 05:59 PM |
which bus more wasteful | Michael S | 2010/10/02 09:38 AM |
which bus more wasteful | rwessel | 2010/10/02 06:15 PM |
Sandy Bridge CPU article online | Ricardo B | 2010/10/01 09:08 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:31 PM |
Sandy Bridge CPU article online | Andi Kleen | 2010/10/01 10:55 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:32 PM |
Sandy Bridge CPU article online | kdg | 2010/10/01 10:26 AM |
Sandy Bridge CPU article online | Anon | 2010/10/01 10:33 AM |
Analog display out? | David Kanter | 2010/10/01 12:05 PM |
Analog display out? | mpx | 2010/10/02 10:46 AM |
Analog display out? | Anon | 2010/10/03 02:26 PM |
Digital is expensive! | David Kanter | 2010/10/03 05:36 PM |
Digital is expensive! | Anon | 2010/10/03 07:07 PM |
Digital is expensive! | David Kanter | 2010/10/03 09:02 PM |
Digital is expensive! | Steve Underwood | 2010/10/04 02:52 AM |
Digital is expensive! | David Kanter | 2010/10/04 06:03 AM |
Digital is expensive! | anonymous | 2010/10/04 06:11 AM |
Digital is not very expensive! | Steve Underwood | 2010/10/04 05:08 PM |
Digital is not very expensive! | Anon | 2010/10/04 07:33 PM |
Digital is not very expensive! | Steve Underwood | 2010/10/04 10:03 PM |
Digital is not very expensive! | mpx | 2010/10/05 12:10 PM |
Digital is not very expensive! | Gabriele Svelto | 2010/10/04 11:24 PM |
Digital is expensive! | jal142 | 2010/10/04 10:46 AM |
Digital is expensive! | mpx | 2010/10/04 12:04 AM |
Digital is expensive! | Gabriele Svelto | 2010/10/04 02:28 AM |
Digital is expensive! | Mark Christiansen | 2010/10/04 02:12 PM |
Analog display out? | slacker | 2010/10/03 05:44 PM |
Analog display out? | Anon | 2010/10/03 07:05 PM |
Analog display out? | Steve Underwood | 2010/10/04 02:48 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:37 PM |
Sandy Bridge CPU article online | slacker | 2010/10/02 01:53 PM |
Sandy Bridge CPU article online | David Hess | 2010/10/02 05:49 PM |
memory bandwith | Max | 2010/09/30 11:19 AM |
memory bandwith | Anon | 2010/10/01 10:28 AM |
memory bandwith | Jack | 2010/10/01 06:45 PM |
memory bandwith | Anon | 2010/10/03 02:19 PM |
Sandy Bridge CPU article online | PiedPiper | 2010/09/30 06:05 PM |
Sandy Bridge CPU article online | Matt Sayler | 2010/09/29 03:38 PM |
Sandy Bridge CPU article online | Jack | 2010/09/29 08:39 PM |
Sandy Bridge CPU article online | mpx | 2010/09/29 11:24 PM |
Sandy Bridge CPU article online | passer | 2010/09/30 02:15 AM |
Sandy Bridge CPU article online | mpx | 2010/09/30 02:47 AM |
Sandy Bridge CPU article online | passer | 2010/09/30 03:25 AM |
SB and web browsing | Rohit | 2010/09/30 05:47 AM |
SB and web browsing | David Hess | 2010/09/30 06:10 AM |
SB and web browsing | MS | 2010/09/30 09:21 AM |
SB and web browsing | passer | 2010/09/30 09:26 AM |
SB and web browsing | MS | 2010/10/02 05:41 PM |
SB and web browsing | Rohit | 2010/10/01 07:02 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/30 07:35 AM |
Sandy Bridge CPU article online | Jack | 2010/09/30 09:40 PM |
processor evolution | hobold | 2010/09/29 01:16 PM |
processor evolution | Foo_ | 2010/09/30 05:10 AM |
processor evolution | Jack | 2010/09/30 06:07 PM |
3D gaming as GPGPU app | hobold | 2010/10/01 03:59 AM |
3D gaming as GPGPU app | Jack | 2010/10/01 06:39 PM |
processor evolution | hobold | 2010/10/01 03:35 AM |
processor evolution | David Kanter | 2010/10/01 09:02 AM |
processor evolution | Anon | 2010/10/01 10:46 AM |
Display | David Kanter | 2010/10/01 12:26 PM |
Display | Rohit | 2010/10/02 01:56 AM |
Display | Linus Torvalds | 2010/10/02 06:40 AM |
Display | rwessel | 2010/10/02 07:58 AM |
Display | sJ | 2010/10/02 09:28 PM |
Display | rwessel | 2010/10/03 07:38 AM |
Display | Anon | 2010/10/03 02:06 PM |
Display tech and compute are different | David Kanter | 2010/10/03 05:33 PM |
Display tech and compute are different | Anon | 2010/10/03 07:16 PM |
Display tech and compute are different | David Kanter | 2010/10/03 09:00 PM |
Display tech and compute are different | hobold | 2010/10/04 12:40 AM |
Display | ? | 2010/10/03 02:02 AM |
Display | Linus Torvalds | 2010/10/03 09:18 AM |
Display | Richard Cownie | 2010/10/03 10:12 AM |
Display | Linus Torvalds | 2010/10/03 11:16 AM |
Display | slacker | 2010/10/03 06:35 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/04 06:06 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/04 10:44 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/04 01:59 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/04 02:13 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/04 07:58 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/05 12:39 AM |
current V12 engines with >6.0 displacement | MS | 2010/10/05 05:57 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/05 12:20 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/05 08:26 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 04:39 AM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 12:22 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/06 02:07 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 02:56 PM |
current V12 engines with >6.0 displacement | rwessel | 2010/10/06 02:30 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 02:53 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/07 12:32 PM |
current V12 engines with >6.0 displacement | rwessel | 2010/10/07 06:54 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 08:02 PM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | slacker | 2010/10/06 06:20 PM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | Ricardo B | 2010/10/07 12:32 AM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | slacker | 2010/10/07 07:15 AM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | Ricardo B | 2010/10/07 09:51 AM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 04:03 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 05:26 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 10:15 PM |
current V12 engines with >6.0 displacement | Howard Chu | 2010/10/07 01:16 PM |
current V12 engines with >6.0 displacement | Anon | 2010/10/05 09:31 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 04:55 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/06 05:15 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 05:34 AM |
I wonder is there any tech area that this forum doesn't have an opinion on (NT) | Rob Thorpe | 2010/10/06 09:11 AM |
Cunieform tablets | David Kanter | 2010/10/06 11:57 AM |
Cunieform tablets | Linus Torvalds | 2010/10/06 12:06 PM |
Ouch...maybe I should hire a new editor (NT) | David Kanter | 2010/10/06 03:38 PM |
Cunieform tablets | rwessel | 2010/10/06 02:41 PM |
Cunieform tablets | seni | 2010/10/07 09:56 AM |
Cunieform tablets | Howard Chu | 2010/10/07 12:44 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/06 05:10 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/06 09:44 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 06:55 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 07:51 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 06:38 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 07:33 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 08:04 PM |
Practical vehicles for commuting | Rob Thorpe | 2010/10/08 04:50 AM |
Practical vehicles for commuting | Gabriele Svelto | 2010/10/08 05:05 AM |
Practical vehicles for commuting | Rob Thorpe | 2010/10/08 05:21 AM |
Practical vehicles for commuting | j | 2010/10/08 01:20 PM |
Practical vehicles for commuting | Rob Thorpe | 2010/12/09 06:00 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/08 09:14 AM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/07 12:23 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/07 03:08 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 04:41 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 07:05 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 07:52 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/08 06:52 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 10:28 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 11:37 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/07 12:37 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/05 01:02 AM |
Display | Linus Torvalds | 2010/10/04 09:39 AM |
Display | Gabriele Svelto | 2010/10/04 11:34 PM |
Display | Richard Cownie | 2010/10/04 05:22 AM |
Display | anon | 2010/10/04 08:22 PM |
Display | Richard Cownie | 2010/10/05 05:42 AM |
Display | mpx | 2010/10/03 10:55 AM |
Display | rcf | 2010/10/03 12:12 PM |
Display | mpx | 2010/10/03 01:36 PM |
Display | rcf | 2010/10/03 04:36 PM |
Display | Ricardo B | 2010/10/04 01:50 PM |
Display | gallier2 | 2010/10/05 02:44 AM |
Display | David Hess | 2010/10/05 04:21 AM |
Display | gallier2 | 2010/10/05 07:21 AM |
Display | David Hess | 2010/10/03 10:21 PM |
Display | rcf | 2010/10/04 07:06 AM |
Display | David Kanter | 2010/10/03 12:54 PM |
Alternative integration | Paul A. Clayton | 2010/10/06 07:51 AM |
Display | slacker | 2010/10/03 06:26 PM |
Display & marketing & analogies | ? | 2010/10/04 01:33 AM |
Display & marketing & analogies | kdg | 2010/10/04 05:00 AM |
Display | Kevin G | 2010/10/02 08:49 AM |
Display | Anon | 2010/10/03 02:43 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/29 02:17 PM |
Sandy Bridge CPU article online | Jack | 2010/09/28 05:27 AM |
Sandy Bridge CPU article online | IntelUser2000 | 2010/09/28 02:07 AM |
Sandy Bridge CPU article online | mpx | 2010/09/28 11:34 AM |
Sandy Bridge CPU article online | Aaron Spink | 2010/09/28 12:28 PM |
Sandy Bridge CPU article online | JoshW | 2010/09/28 01:13 PM |
Sandy Bridge CPU article online | mpx | 2010/09/28 01:54 PM |
Sandy Bridge CPU article online | Foo_ | 2010/09/29 12:19 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 02:06 AM |
Sandy Bridge CPU article online | JS | 2010/09/29 02:42 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 03:03 AM |
Sandy Bridge CPU article online | Foo_ | 2010/09/29 04:55 AM |
Sandy Bridge CPU article online | ajensen | 2010/09/27 11:19 PM |
Sandy Bridge CPU article online | Ian Ollmann | 2010/09/28 03:52 PM |
Sandy Bridge CPU article online | a reader | 2010/09/28 04:05 PM |
Sandy Bridge CPU article online | ajensen | 2010/09/28 10:35 PM |
Updated: Sandy Bridge CPU article | David Kanter | 2010/10/01 04:11 AM |
Updated: Sandy Bridge CPU article | anon | 2011/01/07 08:55 PM |
Updated: Sandy Bridge CPU article | Eric Bron | 2011/01/08 02:29 AM |
Updated: Sandy Bridge CPU article | anon | 2011/01/11 10:24 PM |
Updated: Sandy Bridge CPU article | anon | 2011/01/15 10:21 AM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anon | 2011/01/16 10:22 PM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anonymous | 2011/01/17 01:04 AM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anon | 2011/01/17 06:12 AM |
I can try.... | David Kanter | 2011/01/18 02:54 PM |
I can try.... | anon | 2011/01/18 07:07 PM |
I can try.... | David Kanter | 2011/01/18 10:24 PM |
I can try.... | anon | 2011/01/19 06:51 AM |
Wider fetch than execute makes sense | Paul A. Clayton | 2011/01/19 07:53 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/04 06:29 AM |
Sandy Bridge CPU article online | Seni | 2011/01/04 08:07 PM |
Sandy Bridge CPU article online | hobold | 2011/01/04 10:26 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 01:01 AM |
software assist exceptions | hobold | 2011/01/05 03:36 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 12:58 AM |
Sandy Bridge CPU article online | anon | 2011/01/05 03:51 AM |
Sandy Bridge CPU article online | Seni | 2011/01/05 07:53 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 08:03 AM |
Sandy Bridge CPU article online | anon | 2011/01/05 03:14 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 03:50 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/05 04:00 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 06:26 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/05 06:50 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 07:39 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 02:50 PM |
permuting vector elements | hobold | 2011/01/05 04:03 PM |
permuting vector elements | Nicolas Capens | 2011/01/05 05:01 PM |
permuting vector elements | Nicolas Capens | 2011/01/06 07:27 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/11 10:33 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/11 12:51 PM |
Sandy Bridge CPU article online | hobold | 2011/01/11 01:11 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/11 05:07 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/12 02:25 AM |
Sandy Bridge CPU article online | hobold | 2011/01/12 04:03 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/12 10:27 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/13 01:38 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/13 02:32 AM |
Sandy Bridge CPU article online | hobold | 2011/01/13 12:53 PM |
What happened to VPERMIL2PS? | Michael S | 2011/01/13 02:46 AM |
What happened to VPERMIL2PS? | Eric Bron | 2011/01/13 05:46 AM |
Lower cost permute | Paul A. Clayton | 2011/01/13 11:11 AM |
Sandy Bridge CPU article online | anon | 2011/01/25 05:31 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/12 05:34 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/13 06:38 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/15 08:47 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/16 02:13 AM |
And just to make a further example | Gabriele Svelto | 2011/01/16 03:24 AM |
Sandy Bridge CPU article online | mpx | 2011/01/16 12:27 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/25 01:56 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/25 03:11 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/26 07:49 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/26 03:35 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/27 01:51 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/27 01:40 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/28 02:24 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/28 02:49 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/30 01:11 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/31 02:43 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/01 03:02 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/01 03:28 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/01 03:43 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/28 06:14 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/01 01:58 AM |
Sandy Bridge CPU article online | EduardoS | 2011/02/01 01:36 PM |
Sandy Bridge CPU article online | anon | 2011/02/01 03:56 PM |
Sandy Bridge CPU article online | EduardoS | 2011/02/01 08:17 PM |
Sandy Bridge CPU article online | anon | 2011/02/01 09:13 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/02 03:08 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/02 03:26 AM |
Sandy Bridge CPU article online | kalmaegi | 2011/02/01 08:29 AM |
SW Rasterization | David Kanter | 2011/01/27 04:18 PM |
Lower pin count memory | iz | 2011/01/27 08:19 PM |
Lower pin count memory | David Kanter | 2011/01/27 08:25 PM |
Lower pin count memory | iz | 2011/01/27 10:31 PM |
Lower pin count memory | David Kanter | 2011/01/27 10:52 PM |
Lower pin count memory | iz | 2011/01/27 11:28 PM |
Lower pin count memory | David Kanter | 2011/01/28 12:05 AM |
Lower pin count memory | iz | 2011/01/28 02:55 AM |
Lower pin count memory | David Hess | 2011/01/28 12:15 PM |
Lower pin count memory | David Kanter | 2011/01/28 12:57 PM |
Lower pin count memory | iz | 2011/01/28 04:20 PM |
Two years later | ForgotPants | 2013/10/26 10:33 AM |
Two years later | anon | 2013/10/26 10:36 AM |
Two years later | Exophase | 2013/10/26 11:56 AM |
Two years later | David Hess | 2013/10/26 04:05 PM |
Herz is totally the thing you DON*T care. | Jouni Osmala | 2013/10/27 12:48 AM |
Herz is totally the thing you DON*T care. | EduardoS | 2013/10/27 06:00 AM |
Herz is totally the thing you DON*T care. | Michael S | 2013/10/27 06:45 AM |
Two years later | someone | 2013/10/28 06:21 AM |
Lower pin count memory | Martin Høyer Kristiansen | 2011/01/28 12:41 AM |
Lower pin count memory | iz | 2011/01/28 02:07 AM |
Lower pin count memory | Darrell Coker | 2011/01/27 09:39 PM |
Lower pin count memory | iz | 2011/01/27 11:20 PM |
Lower pin count memory | Darrell Coker | 2011/01/28 05:07 PM |
Lower pin count memory | iz | 2011/01/28 10:57 PM |
Lower pin count memory | Darrell Coker | 2011/01/29 01:21 AM |
Lower pin count memory | iz | 2011/01/31 09:28 PM |
SW Rasterization | Nicolas Capens | 2011/02/02 07:48 AM |
SW Rasterization | Eric Bron | 2011/02/02 08:37 AM |
SW Rasterization | Nicolas Capens | 2011/02/02 03:35 PM |
SW Rasterization | Eric Bron | 2011/02/02 04:11 PM |
SW Rasterization | Eric Bron | 2011/02/03 01:13 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 06:57 AM |
SW Rasterization | Eric Bron | 2011/02/04 07:50 AM |
erratum | Eric Bron | 2011/02/04 07:58 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 04:25 PM |
SW Rasterization | David Kanter | 2011/02/04 04:33 PM |
SW Rasterization | anon | 2011/02/04 05:04 PM |
SW Rasterization | Nicolas Capens | 2011/02/05 02:39 PM |
SW Rasterization | David Kanter | 2011/02/05 04:07 PM |
SW Rasterization | Nicolas Capens | 2011/02/05 10:39 PM |
SW Rasterization | Eric Bron | 2011/02/04 09:55 AM |
Comments pt 1 | David Kanter | 2011/02/02 12:08 PM |
Comments pt 1 | Eric Bron | 2011/02/02 02:16 PM |
Comments pt 1 | Gabriele Svelto | 2011/02/03 12:37 AM |
Comments pt 1 | Eric Bron | 2011/02/03 01:36 AM |
Comments pt 1 | Nicolas Capens | 2011/02/03 10:08 PM |
Comments pt 1 | Nicolas Capens | 2011/02/03 09:26 PM |
Comments pt 1 | Eric Bron | 2011/02/04 02:33 AM |
Comments pt 1 | Nicolas Capens | 2011/02/04 04:24 AM |
example code | Eric Bron | 2011/02/04 03:51 AM |
example code | Nicolas Capens | 2011/02/04 07:24 AM |
example code | Eric Bron | 2011/02/04 07:36 AM |
example code | Nicolas Capens | 2011/02/05 10:43 PM |
Comments pt 1 | Rohit | 2011/02/04 11:43 AM |
Comments pt 1 | Nicolas Capens | 2011/02/04 04:05 PM |
Comments pt 1 | David Kanter | 2011/02/04 04:36 PM |
Comments pt 1 | Nicolas Capens | 2011/02/05 01:45 PM |
Comments pt 1 | Eric Bron | 2011/02/05 03:13 PM |
Comments pt 1 | Nicolas Capens | 2011/02/05 10:52 PM |
Comments pt 1 | Eric Bron | 2011/02/06 12:31 AM |
Comments pt 1 | Nicolas Capens | 2011/02/06 03:06 PM |
Comments pt 1 | Eric Bron | 2011/02/07 02:12 AM |
The need for gather/scatter support | Nicolas Capens | 2011/02/10 09:07 AM |
The need for gather/scatter support | Eric Bron | 2011/02/11 02:11 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/13 02:39 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 06:46 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 06:48 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 08:32 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 09:07 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 08:00 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 06:49 AM |
Gather/scatter performance data | Eric Bron | 2011/02/15 01:23 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 04:06 PM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 06:52 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 08:43 AM |
SW Rasterization - a long way off | Rohit | 2011/02/02 12:17 PM |
SW Rasterization - a long way off | Nicolas Capens | 2011/02/04 02:59 AM |
CPU only rendering - a long way off | Rohit | 2011/02/04 10:52 AM |
CPU only rendering - a long way off | Nicolas Capens | 2011/02/04 06:15 PM |
CPU only rendering - a long way off | Rohit | 2011/02/05 01:00 AM |
CPU only rendering - a long way off | Nicolas Capens | 2011/02/05 08:45 PM |
CPU only rendering - a long way off | David Kanter | 2011/02/06 08:51 PM |
CPU only rendering - a long way off | Gian-Carlo Pascutto | 2011/02/06 11:22 PM |
Encryption | David Kanter | 2011/02/07 12:18 AM |
Encryption | Nicolas Capens | 2011/02/07 06:51 AM |
Encryption | David Kanter | 2011/02/07 10:50 AM |
Encryption | Nicolas Capens | 2011/02/08 09:26 AM |
CPUs are latency optimized | David Kanter | 2011/02/08 10:38 AM |
efficient compiler on an efficient GPU real today. | sJ | 2011/02/08 10:29 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/09 08:49 PM |
CPUs are latency optimized | Eric Bron | 2011/02/09 11:49 PM |
CPUs are latency optimized | Antti-Ville Tuunainen | 2011/02/10 05:16 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/10 06:04 AM |
CPUs are latency optimized | Eric Bron | 2011/02/10 06:48 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/10 12:31 PM |
CPUs are latency optimized | Eric Bron | 2011/02/11 01:43 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/11 06:31 AM |
CPUs are latency optimized | EduardoS | 2011/02/10 04:29 PM |
CPUs are latency optimized | Anon | 2011/02/10 05:40 PM |
CPUs are latency optimized | David Kanter | 2011/02/10 07:33 PM |
CPUs are latency optimized | EduardoS | 2011/02/11 01:18 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/11 04:56 AM |
CPUs are latency optimized | Rohit | 2011/02/11 06:33 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/14 01:19 AM |
CPUs are latency optimized | Eric Bron | 2011/02/14 02:23 AM |
CPUs are latency optimized | EduardoS | 2011/02/14 12:11 PM |
CPUs are latency optimized | David Kanter | 2011/02/11 01:45 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/15 04:22 AM |
CPUs are latency optimized | David Kanter | 2011/02/15 11:47 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/15 06:10 PM |
Have fun | David Kanter | 2011/02/15 09:04 PM |
Have fun | Nicolas Capens | 2011/02/17 02:59 AM |
Have fun | Brett | 2011/02/17 11:56 AM |
Have fun | Nicolas Capens | 2011/02/19 03:53 PM |
Have fun | Brett | 2011/02/20 05:08 PM |
Have fun | Brett | 2011/02/20 06:13 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/02/23 04:37 PM |
On-die storage to fight Amdahl | Brett | 2011/02/23 08:59 PM |
On-die storage to fight Amdahl | Brett | 2011/02/23 09:08 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/02/24 06:42 PM |
On-die storage to fight Amdahl | Rohit | 2011/02/25 10:02 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/03/09 05:53 PM |
On-die storage to fight Amdahl | Rohit | 2011/03/10 07:02 AM |
NVIDIA using tile based rendering? | Nathan Monson | 2011/03/11 06:58 PM |
NVIDIA using tile based rendering? | Rohit | 2011/03/12 03:29 AM |
NVIDIA using tile based rendering? | Nathan Monson | 2011/03/12 10:05 AM |
NVIDIA using tile based rendering? | Rohit | 2011/03/12 10:16 AM |
On-die storage to fight Amdahl | Brett | 2011/02/26 01:10 AM |
On-die storage to fight Amdahl | Nathan Monson | 2011/02/26 12:51 PM |
On-die storage to fight Amdahl | Brett | 2011/02/26 03:40 PM |
Convergence is inevitable | Nicolas Capens | 2011/03/09 07:22 PM |
Convergence is inevitable | Brett | 2011/03/09 09:59 PM |
Convergence is inevitable | Antti-Ville Tuunainen | 2011/03/10 02:34 PM |
Convergence is inevitable | Brett | 2011/03/10 08:39 PM |
Procedural texturing? | David Kanter | 2011/03/11 12:32 AM |
Procedural texturing? | hobold | 2011/03/11 02:59 AM |
Procedural texturing? | Dan Downs | 2011/03/11 08:28 AM |
Procedural texturing? | Mark Roulo | 2011/03/11 01:58 PM |
Procedural texturing? | Anon | 2011/03/11 05:11 PM |
Procedural texturing? | Nathan Monson | 2011/03/11 06:30 PM |
Procedural texturing? | Brett | 2011/03/15 06:45 AM |
Procedural texturing? | Seni | 2011/03/15 09:13 AM |
Procedural texturing? | Brett | 2011/03/15 10:45 AM |
Procedural texturing? | Seni | 2011/03/15 01:09 PM |
Procedural texturing? | Brett | 2011/03/11 09:02 PM |
Procedural texturing? | Brett | 2011/03/11 08:34 PM |
Procedural texturing? | Eric Bron | 2011/03/12 02:37 AM |
Convergence is inevitable | Jouni Osmala | 2011/03/09 10:28 PM |
Convergence is inevitable | Brett | 2011/04/05 04:08 PM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 04:23 AM |
Convergence is inevitable | none | 2011/04/07 06:03 AM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 09:34 AM |
Convergence is inevitable | anon | 2011/04/07 01:15 PM |
Convergence is inevitable | none | 2011/04/08 12:57 AM |
Convergence is inevitable | Brett | 2011/04/07 07:04 PM |
Convergence is inevitable | none | 2011/04/08 01:14 AM |
Gather implementation | David Kanter | 2011/04/08 11:01 AM |
RAM Latency | David Hess | 2011/04/07 07:22 AM |
RAM Latency | Brett | 2011/04/07 06:20 PM |
RAM Latency | Nicolas Capens | 2011/04/07 09:18 PM |
RAM Latency | Brett | 2011/04/08 04:33 AM |
RAM Latency | Nicolas Capens | 2011/04/10 01:23 PM |
RAM Latency | Rohit | 2011/04/08 05:57 AM |
RAM Latency | Nicolas Capens | 2011/04/10 12:23 PM |
RAM Latency | David Kanter | 2011/04/10 01:27 PM |
RAM Latency | Rohit | 2011/04/11 05:17 AM |
Convergence is inevitable | Eric Bron | 2011/04/07 08:46 AM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 08:50 PM |
Convergence is inevitable | Eric Bron | 2011/04/07 11:39 PM |
Flaws in PowerVR | Rohit | 2011/02/25 10:21 PM |
Flaws in PowerVR | Brett | 2011/02/25 11:37 PM |
Flaws in PowerVR | Paul | 2011/02/26 04:17 AM |
Have fun | David Kanter | 2011/02/18 11:52 AM |
Have fun | Michael S | 2011/02/19 11:12 AM |
Have fun | David Kanter | 2011/02/19 02:26 PM |
Have fun | Michael S | 2011/02/19 03:43 PM |
Have fun | anon | 2011/02/19 04:02 PM |
Have fun | Michael S | 2011/02/19 04:56 PM |
Have fun | anon | 2011/02/20 02:50 PM |
Have fun | EduardoS | 2011/02/20 01:44 PM |
Linear vs non-linear | EduardoS | 2011/02/20 01:55 PM |
Have fun | Michael S | 2011/02/20 03:19 PM |
Have fun | EduardoS | 2011/02/20 04:51 PM |
Have fun | Nicolas Capens | 2011/02/21 10:12 AM |
Have fun | Michael S | 2011/02/21 11:38 AM |
Have fun | Eric Bron | 2011/02/21 01:10 PM |
Have fun | Eric Bron | 2011/02/21 01:39 PM |
Have fun | Michael S | 2011/02/21 05:13 PM |
Have fun | Eric Bron | 2011/02/21 11:43 PM |
Have fun | Michael S | 2011/02/22 12:47 AM |
Have fun | Eric Bron | 2011/02/22 01:10 AM |
Have fun | Michael S | 2011/02/22 10:37 AM |
Have fun | anon | 2011/02/22 12:38 PM |
Have fun | EduardoS | 2011/02/22 02:49 PM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/23 05:37 PM |
Gather/scatter efficiency | anonymous | 2011/02/23 05:51 PM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/24 05:57 PM |
Gather/scatter efficiency | anonymous | 2011/02/24 06:16 PM |
Gather/scatter efficiency | Michael S | 2011/02/25 06:45 AM |
Gather implementation | David Kanter | 2011/02/25 04:34 PM |
Gather implementation | Michael S | 2011/02/26 09:40 AM |
Gather implementation | anon | 2011/02/26 10:52 AM |
Gather implementation | Michael S | 2011/02/26 11:16 AM |
Gather implementation | anon | 2011/02/26 10:22 PM |
Gather implementation | Michael S | 2011/02/27 06:23 AM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/28 02:14 PM |
Consider yourself ignored | David Kanter | 2011/02/22 12:05 AM |
one more anti-FMA flame. By me. | Michael S | 2011/02/16 06:40 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/16 07:30 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/16 08:15 AM |
one more anti-FMA flame. By me. | Nicolas Capens | 2011/02/17 05:27 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/17 06:42 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/17 04:46 PM |
Tarantula paper | Paul A. Clayton | 2011/02/17 11:38 PM |
Tarantula paper | Nicolas Capens | 2011/02/19 04:19 PM |
anti-FMA != anti-throughput or anti-SG | Eric Bron | 2011/02/18 12:48 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/20 02:46 PM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/20 04:00 PM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 03:05 AM |
Software pipelining on x86 | David Kanter | 2011/02/23 04:04 AM |
Software pipelining on x86 | JS | 2011/02/23 04:25 AM |
Software pipelining on x86 | Salvatore De Dominicis | 2011/02/23 07:37 AM |
Software pipelining on x86 | Jouni Osmala | 2011/02/23 08:10 AM |
Software pipelining on x86 | LeeMiller | 2011/02/23 09:07 PM |
Software pipelining on x86 | Nicolas Capens | 2011/02/24 02:17 PM |
Software pipelining on x86 | anonymous | 2011/02/24 06:04 PM |
Software pipelining on x86 | Nicolas Capens | 2011/02/28 08:27 AM |
Software pipelining on x86 | Antti-Ville Tuunainen | 2011/03/02 03:31 AM |
Software pipelining on x86 | Megol | 2011/03/02 11:55 AM |
Software pipelining on x86 | Geert Bosch | 2011/03/03 06:58 AM |
FMA benefits and latency predictions | David Kanter | 2011/02/25 04:14 PM |
FMA benefits and latency predictions | Antti-Ville Tuunainen | 2011/02/26 09:43 AM |
FMA benefits and latency predictions | Matt Waldhauer | 2011/02/27 05:42 AM |
FMA benefits and latency predictions | Nicolas Capens | 2011/03/09 05:11 PM |
FMA benefits and latency predictions | Rohit | 2011/03/10 07:11 AM |
FMA benefits and latency predictions | Eric Bron | 2011/03/10 08:30 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/23 04:19 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 06:50 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/23 09:37 AM |
FMA and beyond | Nicolas Capens | 2011/02/24 03:47 PM |
detour on terminology | hobold | 2011/02/24 06:08 PM |
detour on terminology | Nicolas Capens | 2011/02/28 01:24 PM |
detour on terminology | Eric Bron | 2011/03/01 01:38 AM |
detour on terminology | Michael S | 2011/03/01 04:03 AM |
detour on terminology | Eric Bron | 2011/03/01 04:39 AM |
detour on terminology | Michael S | 2011/03/01 07:33 AM |
detour on terminology | Eric Bron | 2011/03/01 08:34 AM |
erratum | Eric Bron | 2011/03/01 08:54 AM |
detour on terminology | Nicolas Capens | 2011/03/10 07:39 AM |
detour on terminology | Eric Bron | 2011/03/10 08:50 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 05:12 AM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 10:25 PM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/17 05:51 PM |
Tarantula vector unit well-integrated | Paul A. Clayton | 2011/02/17 11:38 PM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/19 01:17 PM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 01:09 AM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/20 08:55 AM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 12:39 PM |
anti-FMA != anti-throughput or anti-SG | EduardoS | 2011/02/20 01:35 PM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/21 07:12 AM |
anti-FMA != anti-throughput or anti-SG | anon | 2011/02/17 09:44 PM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/18 05:20 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/17 07:24 AM |
thanks | Michael S | 2011/02/17 03:56 PM |
CPUs are latency optimized | EduardoS | 2011/02/15 12:24 PM |
SwiftShader SNB test | Eric Bron | 2011/02/15 02:46 PM |
SwiftShader NHM test | Eric Bron | 2011/02/15 03:50 PM |
SwiftShader SNB test | Nicolas Capens | 2011/02/16 11:06 PM |
SwiftShader SNB test | Eric Bron | 2011/02/17 12:21 AM |
SwiftShader SNB test | Eric Bron | 2011/02/22 09:32 AM |
SwiftShader SNB test 2nd run | Eric Bron | 2011/02/22 09:51 AM |
SwiftShader SNB test 2nd run | Nicolas Capens | 2011/02/23 01:14 PM |
SwiftShader SNB test 2nd run | Eric Bron | 2011/02/23 01:42 PM |
Win7SP1 out but no AVX hype? | Michael S | 2011/02/24 02:14 AM |
Win7SP1 out but no AVX hype? | Eric Bron | 2011/02/24 02:39 AM |
CPUs are latency optimized | Eric Bron | 2011/02/15 07:02 AM |
CPUs are latency optimized | EduardoS | 2011/02/11 02:40 PM |
CPU only rendering - not a long way off | Nicolas Capens | 2011/02/07 05:45 AM |
CPU only rendering - not a long way off | David Kanter | 2011/02/07 11:09 AM |
CPU only rendering - not a long way off | anonymous | 2011/02/07 09:25 PM |
Sandy Bridge IGP EUs | David Kanter | 2011/02/07 10:22 PM |
Sandy Bridge IGP EUs | Hannes | 2011/02/08 04:59 AM |
SW Rasterization - Why? | Seni | 2011/02/02 01:53 PM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/10 02:12 PM |
Market reasons to ditch the IGP | Seni | 2011/02/11 04:42 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/16 03:29 AM |
Market reasons to ditch the IGP | Seni | 2011/02/16 12:39 PM |
An excellent post! | David Kanter | 2011/02/16 02:18 PM |
CPUs clock higher | Moritz | 2011/02/17 07:06 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/18 05:22 PM |
Market reasons to ditch the IGP | IntelUser2000 | 2011/02/18 06:20 PM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/21 01:42 PM |
Bad data (repeated) | David Kanter | 2011/02/21 11:21 PM |
Bad data (repeated) | none | 2011/02/22 02:04 AM |
13W or 8W? | Foo_ | 2011/02/22 05:00 AM |
13W or 8W? | Linus Torvalds | 2011/02/22 07:58 AM |
13W or 8W? | David Kanter | 2011/02/22 10:33 AM |
13W or 8W? | Mark Christiansen | 2011/02/22 01:47 PM |
Bigger picture | Nicolas Capens | 2011/02/24 05:33 PM |
Bigger picture | Nicolas Capens | 2011/02/24 07:06 PM |
20+ Watt | Nicolas Capens | 2011/02/24 07:18 PM |
<20W | David Kanter | 2011/02/25 12:13 PM |
>20W | Nicolas Capens | 2011/03/08 06:34 PM |
IGP is 3X more efficient | David Kanter | 2011/03/08 09:53 PM |
IGP is 3X more efficient | Eric Bron | 2011/03/09 01:44 AM |
>20W | Eric Bron | 2011/03/09 02:48 AM |
Specious data and claims are still specious | David Kanter | 2011/02/25 01:38 AM |
IGP power consumption, LRB samplers | Nicolas Capens | 2011/03/08 05:24 PM |
IGP power consumption, LRB samplers | EduardoS | 2011/03/08 05:52 PM |
IGP power consumption, LRB samplers | Rohit | 2011/03/09 06:42 AM |
Market reasons to ditch the IGP | none | 2011/02/22 01:58 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/24 05:43 PM |
Market reasons to ditch the IGP | slacker | 2011/02/22 01:32 PM |
Market reasons to ditch the IGP | Seni | 2011/02/18 08:51 PM |
Correction - 28 comparators, not 36. (NT) | Seni | 2011/02/18 09:03 PM |
Market reasons to ditch the IGP | Gabriele Svelto | 2011/02/19 12:49 AM |
Market reasons to ditch the IGP | Seni | 2011/02/19 10:59 AM |
Market reasons to ditch the IGP | Exophase | 2011/02/20 09:43 AM |
Market reasons to ditch the IGP | EduardoS | 2011/02/19 09:13 AM |
Market reasons to ditch the IGP | Seni | 2011/02/19 10:46 AM |
The next revolution | Nicolas Capens | 2011/02/22 02:33 AM |
The next revolution | Gabriele Svelto | 2011/02/22 08:15 AM |
The next revolution | Eric Bron | 2011/02/22 08:48 AM |
The next revolution | Nicolas Capens | 2011/02/23 06:39 PM |
The next revolution | Gabriele Svelto | 2011/02/23 11:43 PM |
GPGPU content creation (or lack of it) | Nicolas Capens | 2011/02/28 06:39 AM |
GPGPU content creation (or lack of it) | The market begs to differ | 2011/03/01 05:32 AM |
GPGPU content creation (or lack of it) | Nicolas Capens | 2011/03/09 08:14 PM |
GPGPU content creation (or lack of it) | Gabriele Svelto | 2011/03/10 12:01 AM |
The market begs to differ | Gabriele Svelto | 2011/03/01 05:33 AM |
The next revolution | Anon | 2011/02/24 01:15 AM |
The next revolution | Nicolas Capens | 2011/02/28 01:34 PM |
The next revolution | Seni | 2011/02/22 01:02 PM |
The next revolution | Gabriele Svelto | 2011/02/23 05:27 AM |
The next revolution | Seni | 2011/02/23 08:03 AM |
The next revolution | Nicolas Capens | 2011/02/24 05:11 AM |
The next revolution | Seni | 2011/02/24 07:45 PM |
IGP sampler count | Nicolas Capens | 2011/03/03 04:19 AM |
Latency and throughput optimized cores | Nicolas Capens | 2011/03/07 02:28 PM |
The real reason no IGP /CPU converge. | Jouni Osmala | 2011/03/07 10:34 PM |
Still converging | Nicolas Capens | 2011/03/13 02:08 PM |
Homogeneous CPU advantages | Nicolas Capens | 2011/03/07 11:12 PM |
Homogeneous CPU advantages | Seni | 2011/03/08 08:23 AM |
Homogeneous CPU advantages | David Kanter | 2011/03/08 10:16 AM |
Homogeneous CPU advantages | Brett | 2011/03/09 02:37 AM |
Homogeneous CPU advantages | Jouni Osmala | 2011/03/08 11:27 PM |
SW Rasterization | firsttimeposter | 2011/02/03 10:18 PM |
SW Rasterization | Nicolas Capens | 2011/02/04 03:48 AM |
SW Rasterization | Eric Bron | 2011/02/04 04:14 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 07:36 AM |
SW Rasterization | Eric Bron | 2011/02/04 07:42 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/26 02:23 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/02/04 03:31 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/05 07:46 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/02/06 05:20 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/06 05:07 PM |
Sandy Bridge CPU article online | arch.comp | 2011/01/06 09:58 PM |
Sandy Bridge CPU article online | Seni | 2011/01/07 09:25 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 03:28 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 05:06 AM |
permuting vector elements (yet again) | hobold | 2011/01/05 04:15 PM |
permuting vector elements (yet again) | Nicolas Capens | 2011/01/06 05:11 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/05 11:46 AM |
wow ...! | hobold | 2011/01/05 04:19 PM |
wow ...! | Nicolas Capens | 2011/01/05 05:11 PM |
wow ...! | Eric Bron | 2011/01/05 09:46 PM |
compress LUT | Eric Bron | 2011/01/05 10:05 PM |
wow ...! | Michael S | 2011/01/06 01:25 AM |
wow ...! | Nicolas Capens | 2011/01/06 05:26 AM |
wow ...! | Eric Bron | 2011/01/06 08:08 AM |
wow ...! | Nicolas Capens | 2011/01/07 06:19 AM |
wow ...! | Steve Underwood | 2011/01/07 09:53 PM |
saturation | hobold | 2011/01/08 09:25 AM |
saturation | Steve Underwood | 2011/01/08 11:38 AM |
saturation | Michael S | 2011/01/08 12:05 PM |
128 bit floats | Brett | 2011/01/08 12:39 PM |
128 bit floats | Michael S | 2011/01/08 01:10 PM |
128 bit floats | Anil Maliyekkel | 2011/01/08 02:46 PM |
128 bit floats | Kevin G | 2011/02/27 10:15 AM |
128 bit floats | hobold | 2011/02/27 03:42 PM |
128 bit floats | Ian Ollmann | 2011/02/28 03:56 PM |
OpenCL FP accuracy | hobold | 2011/03/01 05:45 AM |
OpenCL FP accuracy | anon | 2011/03/01 07:03 PM |
OpenCL FP accuracy | hobold | 2011/03/02 02:53 AM |
OpenCL FP accuracy | Eric Bron | 2011/03/02 06:10 AM |
pet project | hobold | 2011/03/02 08:22 AM |
pet project | Anon | 2011/03/02 08:10 PM |
pet project | hobold | 2011/03/03 03:57 AM |
pet project | Eric Bron | 2011/03/03 01:29 AM |
pet project | hobold | 2011/03/03 04:14 AM |
pet project | Eric Bron | 2011/03/03 02:10 PM |
pet project | hobold | 2011/03/03 03:04 PM |
OpenCL and AMD | Vincent Diepeveen | 2011/03/07 12:44 PM |
OpenCL and AMD | Eric Bron | 2011/03/08 01:05 AM |
OpenCL and AMD | Vincent Diepeveen | 2011/03/08 07:27 AM |
128 bit floats | Michael S | 2011/02/27 03:46 PM |
128 bit floats | Anil Maliyekkel | 2011/02/27 05:14 PM |
saturation | Steve Underwood | 2011/01/17 03:42 AM |
wow ...! | hobold | 2011/01/06 04:05 PM |
Ring | Moritz | 2011/01/20 09:51 PM |
Ring | Antti-Ville Tuunainen | 2011/01/21 11:25 AM |
Ring | Moritz | 2011/01/23 12:38 AM |
Ring | Michael S | 2011/01/23 03:04 AM |
So fast | Moritz | 2011/01/23 06:57 AM |
So fast | David Kanter | 2011/01/23 09:05 AM |
Sandy Bridge CPU (L1D cache) | Gordon Ward | 2011/09/09 01:47 AM |
Sandy Bridge CPU (L1D cache) | David Kanter | 2011/09/09 03:19 PM |
Sandy Bridge CPU (L1D cache) | EduardoS | 2011/09/09 07:53 PM |
Sandy Bridge CPU (L1D cache) | Paul A. Clayton | 2011/09/10 04:12 AM |
Sandy Bridge CPU (L1D cache) | Michael S | 2011/09/10 08:41 AM |
Sandy Bridge CPU (L1D cache) | EduardoS | 2011/09/10 10:17 AM |
Address Ports on Sandy Bridge Scheduler | Victor | 2011/10/16 05:40 AM |
Address Ports on Sandy Bridge Scheduler | EduardoS | 2011/10/16 06:45 PM |
Address Ports on Sandy Bridge Scheduler | Megol | 2011/10/17 08:20 AM |
Address Ports on Sandy Bridge Scheduler | Victor | 2011/10/18 04:34 PM |
Benefits of early scheduling | Paul A. Clayton | 2011/10/18 05:53 PM |
Benefits of early scheduling | Victor | 2011/10/19 04:58 PM |
Consistency and invalidation ordering | Paul A. Clayton | 2011/10/20 03:43 AM |
Address Ports on Sandy Bridge Scheduler | John Upcroft | 2011/10/21 03:16 PM |
Address Ports on Sandy Bridge Scheduler | David Kanter | 2011/10/22 09:49 AM |
Address Ports on Sandy Bridge Scheduler | John Upcroft | 2011/10/26 12:24 PM |
Store TLB look-up at commit? | Paul A. Clayton | 2011/10/26 07:30 PM |
Store TLB look-up at commit? | Richard Scott | 2011/10/26 08:40 PM |
Just a guess | Paul A. Clayton | 2011/10/27 12:54 PM |