By: Seni (seniike.delete@this.hotmail.com), February 16, 2011 1:39 pm
Room: Moderated Discussions
Nicolas Capens (nicolas.capens@gmail.com) on 2/16/11 wrote:
---------------------------
>Hi Seni,
>
>Seni (seniike@hotmail.com) on 2/11/11 wrote:
>---------------------------
>>>>>So instead of a multi-core CPU with an IGP you might as well have a CPU with a couple more cores.
>>>>
>>>>I'm wondering why you think there is a viable market segment that is too cheap
>>>>to pay $5 for an IGP and yet wants more cores.
>>>>Outside of the server market, some workstations, and a few other niches, the extra cores are not all that useful.
>>>>And the things they work for are things that GPUs do too - media transcoding, offline rendering, games, etc.
>>>>Why would someone who wants no GPU want more cores?
>>>
>>>First of all, an IGP does not cost 5 $. A quad-core Sandy Bridge costs at least
>>>177 $ and the IGP takes 18% of die space. That's over 30 $.
>>>
>>
>>You can't just divide and get the cost like that. The actual cost of the die area
>>is quite small - around $20 for the entire Sandy Bridge chip. The rest of the cost goes to:
>>- cost of the fab
>>- package/pins
>>- testing/binning
>>- cost of the process R&D
>>- cost of the chip design
>>- cost of validation & verification
>>- cost of the mask set
>>- cost of writing drivers
>>- cost of marketing programs
>>- and so on.
>
>If this was a valid argument then a Core i3 would cost only 5$ less than a Core
>i7. Clearly things like testing/binning, R&D/design/validation/verification, mask
>set and drivers also affect the IGP cost.
>
Price is not the same as cost.
Intel can charge different prices for products that are almost the same cost.
>Comparing the area really isn't a bad approximation of the real cost. In fact is
>should be higher since it's entirely different testing/binning and R&D/design/validation/verification
>compared to just varying the number of CPU cores.
>
>>The cost of the die area for the IGP really is about $5. But compared to the way
>>they did it before, moving the IGP onto the CPU probably saves more than $5, so really it's free.
>
>Making one thing a little cheaper doesn't mean some other expensive part suddenly
>became free. The total cost for the IGP is a lot higher than the ~5$ of the chip
>cost alone, and you can save a significant part of this total cost. A 6-core CPU
>would be cheaper than a quad-core with IGP.
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?
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)
I think mask costs are pretty much a constant term + a linear term for chip area.
So the mask is more expensive with an IGP than without, but sublinearly, and if the die area were spent on cores or cache instead, the cost would come out the same.
Package and pincount cost is pretty small for an on-chip IGP, but is dramatically higher for a northbridge IGP or a discrete video card.
Software rendering would probably have comparable pincounts to on-chip IGP, except if it makes inefficient use of bandwidth or power (which it almost certainly would).
>>If they did it your way and didn't design an IGP at all, they could save both
>the $5 and that last little bit of R&D...
>>Except that instead of spending money on IGP design, they have to spend it on software renderer design.
>
>How many developers do you think it takes to write a software renderer? Pixomatic
>was written by two people. Now compare that to the number of specialized people
>you need to perform all of the above described tasks to get an IGP onto the CPU.
>Note that a big strength of the move to software processing is that there are millions
>of software developers *eager* to develop for powerful homogenous chips. There's
>no significant difference in cost to design a game for the GPU versus the CPU. In
>fact today a great deal of time is wasted trying to figure out how to get the GPU
>to do what you want. Note that taking detours also results in lower effective performance.
>
>So in the long run what you'd get with a homogenous CPU with FMA and gather/scatter
>is a highly competitive software ecosystem with lots of new exciting products, at
"Competitive software ecosystem" sounds like you want to ditch the existing software ecosystem and start over.
Is that your plan? Abandon backward compatibility with DirectX and OpenGL?
>a lower cost to the end user. No need to pay Intel for something you migth not use
>much. Instead, you get more powerful hardware for your money.
>
At this point, I doubt I can convince you regarding either the cost or the performance.
I dispute all of the following:
-a lower cost to the end user by $5, if even that? who cares?
-No need to pay Intel and where do the extra cores and gather/scatter units come from? Not Intel?
-something you migth not use much gpus are used more than you think even at the low end. The Vista/Win7 gui uses them. Also a few non-game programs are gpu-accelerated.
-more powerful hardware for your money unlikely, as explained by pretty much everyone else commenting.
>>>Secondly, not having an IGP doesn't have to mean replacing it with CPU cores. You
>>>can also opt to save 30 $ and still enjoy having a fast CPU which can adequately
>>>take care of 3D graphics should you need it.
>>
>>A cheap CPU wouldn't be adequate for texture filtering even if it had 2 more cores.
>
>Yes it would. The HD Graphics 3000 IGP has just 2 samplers. A 6-core CPU with FMA
>and gather/scatter would be like having up to 12 slightly slower samplers.
>
Each sampler does a 4-texel quad at a time, so 2 of them do 8 texels per cycle.
Each bilinear-filtered texel lookup requires 4 reads from texture memory, so that makes 32 reads per cycle.
Each Sandy-Bridge-like core (without gather/scatter) has a dual-banked L1, dual ported TLB, etc. and cannot handle more than 2 loads per cycle.
So you would need at least 16 cores to match the IGP at equal clock frequency. Or 8 cores if you figure a 2:1 difference in clock. Just to keep up with the current somewhat-crappy IGP.
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.
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.
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.
But it can't do it without a whole lot of bulky supporting hardware which is probably not compatible with a fast OOO x86 core.
>Note also that while the IGPs samplers can be either a bottleneck or running idle,
>a unified design can achieve higher peak throughput and only pays for delivered throughput.
>
While this is true the benefit of sharing two hardware pools is at best 2:1, from reclaiming the half of the units that would have been idle.
If the benefit of specializing the hardware is more than 2:1, then unifying is a net loss.
I'm still not entirely convinced that unified shaders were a good idea, but at least in that case, the shader code is nearly identical.
Unifying it further with the texture units or the framebuffer blending units for example, would probably be a mistake.
>>>Last but not least, people who use a discrete graphics would much rather have a
>>>6-core CPU with gather/scatter than a 4-core CPU + IGP.
>>
>>The people who would want to trade away the IGP for two extra cores, they already
>>can. There is a separate product for them - namely 6-core Gulftown.
>
>Gulftown doesn't have AVX, and requires a socket 1366 motherboard. So Gulftown
>sales are not a useful representation of the market for a future homogenous CPU with FMA and gather/scatter.
>
I think you completely missed the point here.
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...)
You are complaining that Sandy Bridge has too much IGP and not enough cores, but that's because it's not for you. You are in the other market segment.
When the next generations come out, there will still be high-cores/no IGP product and a IGP-based product with less cores.
That is to say, Gulftown will have a successor, and so will Sandy Bridge.
If you're not in the 4-Core+IGP market segment, then you don't buy a Sandy Bridge. You either get a Gulftown, or you wait for Gulftown's successor.
There's nothing to complain about except that you don't like the staggered timing of the product releases.
>>>>Other than misinformed consumers, I expect that market hole is awfully small.
>>>>Generally, consumers either need graphics for gaming, or need neither graphics
>>>>nor cpu power and would be better off with a netbook-class processor.
>>>>The consumer who buys an eight-core processor to browse the web is a fool.
>>>
>>>If that were a valid argument, then there would also be an awfully small market
>>>for Sandy Bridge as-is.
>>
>>Well, firstly, there are many misinformed consumers.
>
>That's true for any product. Most consumers will buy a bigger car than what they
>actually need for daily commutes.
Look at how car sales changed with the rise and fall of gas prices. SUVs and pickup trucks were selling like hotcakes, and then they weren't. And then they are again. And soon they probably won't be again.
So some people buy a car that's more than they need. But they only do it under certain market conditions that are subject to change.
The thing is, misinformed consumers can go in any direction.
They are unpredictable in the longer term and can change behavior with the whims of marketing & fashion.
If your plan is to make an inferior or overpriced product and hope people buy it anyway, it might work. Or it might not.
Making a good product and selling it to informed customers is a more reliable plan (unless you fail at marketing it).
To make a good product, you want to match it to the customer's actual needs, not what they think they need.
And their actual needs, in most cases, is either:
-1 they need a both CPU and a GPU, or
-2 they need basic capability at about a Celeron+IGP level.
In neither case is scrapping the IGP to pack in more cores going to actually help them.
They may not know that yet themselves, but there's a chance that they will catch on. What do you do then?
>So call it misinformation or whatever, people
>will buy the system with the highest performance for the money, even if they could
>do with a little less performance most of the time.
>
They do now. Will it continue? For how long? Who can say for sure?
All it would take is a strong ad campaign from someone people blindly listen too (Apple maybe?) to tell them that multicore CPUs are so uncool, and that some other new thing is the new thing.
Just look at the crash and burn of the Pentium 4/"clockspeed is everything" marketing plan. Suddenly people care about efficiency. The Pentium 4 is now everyone's scapegoat.
>They're still getting a more compelling system. In particular, it should be more
>future proof. History shows that software developers have always come up with ways
>to push the hardware requirements up. The Althon X2 I once paid 500€ for, is now
>a real pain to work on. And my 2500€ laptop with a Core 2 Duo 2.0 GHz is overdue
>for a replacement. And mark my words, multi-core software development is only at
>its infancy. A 6-core CPU is going to look average in just several years time.
>
Right. Performance demand grows over time. But not just demand for cores, but also demand for graphics performance.
You have argued in some of your other posts that you think the demand for graphics performance will saturate, much like the demand for audio performance did.
I don't think this is going to happen anytime soon, given my experience with offline renderers and vast quality gap between them and games.
There is just too much room for further improvement in graphics quality in games.
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.
>>Others think before they buy the computer that they will never play games on it.
>>Then they change their minds after it is too late.
>
>It's exactly the same for the CPU. Most still buy a dual-core CPU, based solely
>on the fact that most applications don't take advantage of more cores just yet.
>But they're not taking into account that the software world moves relatively fast
>and they're best off planning ahead 3-5 years.
>
I agree.
>That said, for a desktop system it's never too late to change your mind about gaming
>performance. You can start with a 6-core CPU performing graphics in software, and
>when it turns out you do play more games than anticipated, you can buy a discrete
>graphics card. If instead you started with a CPU+IGP, you'd have wasted money on
>the IGP. And if you need more CPU power, the CPU+IGP solution requires you to upgrade sooner.
>
You assume that GPU upgrades are possible. On desktops, they are. On laptops, they are not.
The desktop market is slowly collapsing.
You don't upgrade laptops. You buy a one, use it for a while, and then buy a whole new one.
This is the direction the whole market is going.
>>>Noone who calls himself a gamer is going to buy a Sandy
>>>Bridge CPU and use the IGP.
>>
>>You might think an IGP would be useless to someone with a proper GPU. It's not.
>>
>>I bought a laptop in 2008 or so, with a Penryn 6M and a Geforce 8800M. It also has an IGP.
>>It offers a low-power mode that is useful when you don't want to waste power using the real GPU.
>
>That's again something you can get from a homogenous CPU as well. When not running
>games, the near-idle power consumption of a modern CPU is lower than that of a hefty
>GPU.
>And if that changes in future designs due to better power gating in the discrete
>GPU, you still got a more powerful CPU while the IGP became useless. Honestly, falling
>back to the IGP because the GPU takes too much power at low load isn't a feat of
>the IGP but poor power management of the GPU. There's no reason it shouldn't be
>able to shut off partially instead of entirely to achieve a good balance. So using
>the IGP instead is just a short-lived band-aid.
>
I basically agree with this. It is a short-lived band-aid. But it is a band-aid that covers a genuine wound, and only costs $5.
It would be better that there be no wound at all, but as it is it's an ok deal.
>I'm happy for you your setup gives you a pracical advantage for the current reality,
>but it's not a long-term argument pro IGPs.
>
>>More importantly it's a backup in case the Geforce dies. Which in fact, it did.
>>So now I use the IGP. If not for the IGP, the system would be unbootable until
>>I got a replacement GPU, which for laptops is a huge pain.
>>Am I glad I spent the extra $5 to get an IGP? Hell yes!
>
>With all due respect that's just a silly argument. It only shows how unreliable
>GPUs really are. Would you buy a car that comes with a free bike, "in case it breaks
>down"? Personally I'd rather buy from a manufacturer who gives me a higher quality
>guarantee. And note this 'bike' isn't actually free.
>
The relative prices and values matter here.
If I buy a known unreliable sports car on account of its speed and general awesomeness, and for just $5 extra, the dealer throws in a perfectly good motorcycle, I'd say that's a good deal.
Well, maybe buying an unreliable sports car at all is not a good deal, but in this case, the options are sorta limited, as all other cars on this market have problems at least equally bad.
With desktops, if your GPU dies, you can just buy a new video card swap it in.
With a laptop, if you GPU dies and you have no IGP, the entire system is pretty much dead, and the only way to fix it is to send it to the manufacturer who hopefully has the spare part.
I think a backup is worth at least $5.
>Seriously, IGP+GPU systems have no future.
>
>>>>Non-consumers are different, as they have non-graphics servers, and non-graphics workstations.
>>>>But there are separate processor lines for servers and whatnot, so they don't really count here.
>>>
>>>It does count for something because designing an IGP has a high R&D cost. In other
>>>words a 6-core CPU can be cheaper than a 4-core CPU + IGP even if the die size is
>>>exactly the same. Furthermore, having different production lines and testing methods
>>>and all that reduces the efficiency so not having to produce CPUs with an IGP not
>>>only saves R&D but also production cost.
>>
>>Having multiple products is necessary anyway (2-core netbook vs. 4-core laptop
>>vs. 6-core workstation vs. 8-core server)
>>The R&D cost can't be reduced unless they completely eliminate all IGPs from their
>entire product line, including Atom.
>
>Yes, multiple products remain necessary, but not another combination of CPUs with
>and without IGP. Reducing the number of product lines, reduces cost per part.
>
>And you appear to imply that Atom uses the same IGP design as Sandy Bridge.
No, what I'm saying is that they are spawned from different generations of the same product lines made by the same hardware design team.
Intel's current netbook IGPs are based on the previous generations of mainstream IGPs.
All of intel's future netbook IGPs will be based on hand-me-down designs of current and future mainstream IGPs.
So, most of the work gets done once, and is shared over time between the two product lines.
If you shut down the mainstream IGP development, you would also lose your netbook IGP development. It's one and the same.
If you keep the netbook IGP development going at all, then you still pay the full development price that you would have paid for both whether you use it twice or not.
So any plan to replace mainstream IGPs with software rendering is workable only if it also works for netbooks.
When do you expect netbooks to have 8+ cores & gather/scatter support?
Right now Atom doesn't even have a dual ported LSU, and most netbooks are still single-core+HT.
They've got a long way to go to catch up with even the terrible IGP they come with.
> That's
>incorrect. Pineview has a GMA 3150, which is the old Direct3D 9 generation GMA 3100
>shrunk to 45 nm. It does vertex processing in software! If all desktop CPUs eliminate
>the IGP and several years later Atom runs out of IGPs to shrink down, Intel can
>still license cheap IGPs from PowerVR. The cost is lower than designing such an
One problem here is that PowerVR IGP drivers are from hell, and any possible fix seems to be blocked by licensing issues that Intel has little control over.
The other problem is having a PowerVR IGP means having an IGP at all, which is what you are arguing against in the first place, isn't it?
Surely if there is cost savings to be had, the netbook market is the ideal place for it.
>IGP in-house since the PowerVR design is licensed to multiple manufacturers. And
>it's definitely cheaper than continuing to design IGPs suited for the desktop market.
>
>So once again ditching the IGP saves money, which translates into more valuable homogenous CPUs for everyone.
>
>Regards,
>
>Nicolas
---------------------------
>Hi Seni,
>
>Seni (seniike@hotmail.com) on 2/11/11 wrote:
>---------------------------
>>>>>So instead of a multi-core CPU with an IGP you might as well have a CPU with a couple more cores.
>>>>
>>>>I'm wondering why you think there is a viable market segment that is too cheap
>>>>to pay $5 for an IGP and yet wants more cores.
>>>>Outside of the server market, some workstations, and a few other niches, the extra cores are not all that useful.
>>>>And the things they work for are things that GPUs do too - media transcoding, offline rendering, games, etc.
>>>>Why would someone who wants no GPU want more cores?
>>>
>>>First of all, an IGP does not cost 5 $. A quad-core Sandy Bridge costs at least
>>>177 $ and the IGP takes 18% of die space. That's over 30 $.
>>>
>>
>>You can't just divide and get the cost like that. The actual cost of the die area
>>is quite small - around $20 for the entire Sandy Bridge chip. The rest of the cost goes to:
>>- cost of the fab
>>- package/pins
>>- testing/binning
>>- cost of the process R&D
>>- cost of the chip design
>>- cost of validation & verification
>>- cost of the mask set
>>- cost of writing drivers
>>- cost of marketing programs
>>- and so on.
>
>If this was a valid argument then a Core i3 would cost only 5$ less than a Core
>i7. Clearly things like testing/binning, R&D/design/validation/verification, mask
>set and drivers also affect the IGP cost.
>
Price is not the same as cost.
Intel can charge different prices for products that are almost the same cost.
>Comparing the area really isn't a bad approximation of the real cost. In fact is
>should be higher since it's entirely different testing/binning and R&D/design/validation/verification
>compared to just varying the number of CPU cores.
>
>>The cost of the die area for the IGP really is about $5. But compared to the way
>>they did it before, moving the IGP onto the CPU probably saves more than $5, so really it's free.
>
>Making one thing a little cheaper doesn't mean some other expensive part suddenly
>became free. The total cost for the IGP is a lot higher than the ~5$ of the chip
>cost alone, and you can save a significant part of this total cost. A 6-core CPU
>would be cheaper than a quad-core with IGP.
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?
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)
I think mask costs are pretty much a constant term + a linear term for chip area.
So the mask is more expensive with an IGP than without, but sublinearly, and if the die area were spent on cores or cache instead, the cost would come out the same.
Package and pincount cost is pretty small for an on-chip IGP, but is dramatically higher for a northbridge IGP or a discrete video card.
Software rendering would probably have comparable pincounts to on-chip IGP, except if it makes inefficient use of bandwidth or power (which it almost certainly would).
>>If they did it your way and didn't design an IGP at all, they could save both
>the $5 and that last little bit of R&D...
>>Except that instead of spending money on IGP design, they have to spend it on software renderer design.
>
>How many developers do you think it takes to write a software renderer? Pixomatic
>was written by two people. Now compare that to the number of specialized people
>you need to perform all of the above described tasks to get an IGP onto the CPU.
>Note that a big strength of the move to software processing is that there are millions
>of software developers *eager* to develop for powerful homogenous chips. There's
>no significant difference in cost to design a game for the GPU versus the CPU. In
>fact today a great deal of time is wasted trying to figure out how to get the GPU
>to do what you want. Note that taking detours also results in lower effective performance.
>
>So in the long run what you'd get with a homogenous CPU with FMA and gather/scatter
>is a highly competitive software ecosystem with lots of new exciting products, at
"Competitive software ecosystem" sounds like you want to ditch the existing software ecosystem and start over.
Is that your plan? Abandon backward compatibility with DirectX and OpenGL?
>a lower cost to the end user. No need to pay Intel for something you migth not use
>much. Instead, you get more powerful hardware for your money.
>
At this point, I doubt I can convince you regarding either the cost or the performance.
I dispute all of the following:
-a lower cost to the end user by $5, if even that? who cares?
-No need to pay Intel and where do the extra cores and gather/scatter units come from? Not Intel?
-something you migth not use much gpus are used more than you think even at the low end. The Vista/Win7 gui uses them. Also a few non-game programs are gpu-accelerated.
-more powerful hardware for your money unlikely, as explained by pretty much everyone else commenting.
>>>Secondly, not having an IGP doesn't have to mean replacing it with CPU cores. You
>>>can also opt to save 30 $ and still enjoy having a fast CPU which can adequately
>>>take care of 3D graphics should you need it.
>>
>>A cheap CPU wouldn't be adequate for texture filtering even if it had 2 more cores.
>
>Yes it would. The HD Graphics 3000 IGP has just 2 samplers. A 6-core CPU with FMA
>and gather/scatter would be like having up to 12 slightly slower samplers.
>
Each sampler does a 4-texel quad at a time, so 2 of them do 8 texels per cycle.
Each bilinear-filtered texel lookup requires 4 reads from texture memory, so that makes 32 reads per cycle.
Each Sandy-Bridge-like core (without gather/scatter) has a dual-banked L1, dual ported TLB, etc. and cannot handle more than 2 loads per cycle.
So you would need at least 16 cores to match the IGP at equal clock frequency. Or 8 cores if you figure a 2:1 difference in clock. Just to keep up with the current somewhat-crappy IGP.
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.
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.
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.
But it can't do it without a whole lot of bulky supporting hardware which is probably not compatible with a fast OOO x86 core.
>Note also that while the IGPs samplers can be either a bottleneck or running idle,
>a unified design can achieve higher peak throughput and only pays for delivered throughput.
>
While this is true the benefit of sharing two hardware pools is at best 2:1, from reclaiming the half of the units that would have been idle.
If the benefit of specializing the hardware is more than 2:1, then unifying is a net loss.
I'm still not entirely convinced that unified shaders were a good idea, but at least in that case, the shader code is nearly identical.
Unifying it further with the texture units or the framebuffer blending units for example, would probably be a mistake.
>>>Last but not least, people who use a discrete graphics would much rather have a
>>>6-core CPU with gather/scatter than a 4-core CPU + IGP.
>>
>>The people who would want to trade away the IGP for two extra cores, they already
>>can. There is a separate product for them - namely 6-core Gulftown.
>
>Gulftown doesn't have AVX, and requires a socket 1366 motherboard. So Gulftown
>sales are not a useful representation of the market for a future homogenous CPU with FMA and gather/scatter.
>
I think you completely missed the point here.
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...)
You are complaining that Sandy Bridge has too much IGP and not enough cores, but that's because it's not for you. You are in the other market segment.
When the next generations come out, there will still be high-cores/no IGP product and a IGP-based product with less cores.
That is to say, Gulftown will have a successor, and so will Sandy Bridge.
If you're not in the 4-Core+IGP market segment, then you don't buy a Sandy Bridge. You either get a Gulftown, or you wait for Gulftown's successor.
There's nothing to complain about except that you don't like the staggered timing of the product releases.
>>>>Other than misinformed consumers, I expect that market hole is awfully small.
>>>>Generally, consumers either need graphics for gaming, or need neither graphics
>>>>nor cpu power and would be better off with a netbook-class processor.
>>>>The consumer who buys an eight-core processor to browse the web is a fool.
>>>
>>>If that were a valid argument, then there would also be an awfully small market
>>>for Sandy Bridge as-is.
>>
>>Well, firstly, there are many misinformed consumers.
>
>That's true for any product. Most consumers will buy a bigger car than what they
>actually need for daily commutes.
Look at how car sales changed with the rise and fall of gas prices. SUVs and pickup trucks were selling like hotcakes, and then they weren't. And then they are again. And soon they probably won't be again.
So some people buy a car that's more than they need. But they only do it under certain market conditions that are subject to change.
The thing is, misinformed consumers can go in any direction.
They are unpredictable in the longer term and can change behavior with the whims of marketing & fashion.
If your plan is to make an inferior or overpriced product and hope people buy it anyway, it might work. Or it might not.
Making a good product and selling it to informed customers is a more reliable plan (unless you fail at marketing it).
To make a good product, you want to match it to the customer's actual needs, not what they think they need.
And their actual needs, in most cases, is either:
-1 they need a both CPU and a GPU, or
-2 they need basic capability at about a Celeron+IGP level.
In neither case is scrapping the IGP to pack in more cores going to actually help them.
They may not know that yet themselves, but there's a chance that they will catch on. What do you do then?
>So call it misinformation or whatever, people
>will buy the system with the highest performance for the money, even if they could
>do with a little less performance most of the time.
>
They do now. Will it continue? For how long? Who can say for sure?
All it would take is a strong ad campaign from someone people blindly listen too (Apple maybe?) to tell them that multicore CPUs are so uncool, and that some other new thing is the new thing.
Just look at the crash and burn of the Pentium 4/"clockspeed is everything" marketing plan. Suddenly people care about efficiency. The Pentium 4 is now everyone's scapegoat.
>They're still getting a more compelling system. In particular, it should be more
>future proof. History shows that software developers have always come up with ways
>to push the hardware requirements up. The Althon X2 I once paid 500€ for, is now
>a real pain to work on. And my 2500€ laptop with a Core 2 Duo 2.0 GHz is overdue
>for a replacement. And mark my words, multi-core software development is only at
>its infancy. A 6-core CPU is going to look average in just several years time.
>
Right. Performance demand grows over time. But not just demand for cores, but also demand for graphics performance.
You have argued in some of your other posts that you think the demand for graphics performance will saturate, much like the demand for audio performance did.
I don't think this is going to happen anytime soon, given my experience with offline renderers and vast quality gap between them and games.
There is just too much room for further improvement in graphics quality in games.
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.
>>Others think before they buy the computer that they will never play games on it.
>>Then they change their minds after it is too late.
>
>It's exactly the same for the CPU. Most still buy a dual-core CPU, based solely
>on the fact that most applications don't take advantage of more cores just yet.
>But they're not taking into account that the software world moves relatively fast
>and they're best off planning ahead 3-5 years.
>
I agree.
>That said, for a desktop system it's never too late to change your mind about gaming
>performance. You can start with a 6-core CPU performing graphics in software, and
>when it turns out you do play more games than anticipated, you can buy a discrete
>graphics card. If instead you started with a CPU+IGP, you'd have wasted money on
>the IGP. And if you need more CPU power, the CPU+IGP solution requires you to upgrade sooner.
>
You assume that GPU upgrades are possible. On desktops, they are. On laptops, they are not.
The desktop market is slowly collapsing.
You don't upgrade laptops. You buy a one, use it for a while, and then buy a whole new one.
This is the direction the whole market is going.
>>>Noone who calls himself a gamer is going to buy a Sandy
>>>Bridge CPU and use the IGP.
>>
>>You might think an IGP would be useless to someone with a proper GPU. It's not.
>>
>>I bought a laptop in 2008 or so, with a Penryn 6M and a Geforce 8800M. It also has an IGP.
>>It offers a low-power mode that is useful when you don't want to waste power using the real GPU.
>
>That's again something you can get from a homogenous CPU as well. When not running
>games, the near-idle power consumption of a modern CPU is lower than that of a hefty
>GPU.
>And if that changes in future designs due to better power gating in the discrete
>GPU, you still got a more powerful CPU while the IGP became useless. Honestly, falling
>back to the IGP because the GPU takes too much power at low load isn't a feat of
>the IGP but poor power management of the GPU. There's no reason it shouldn't be
>able to shut off partially instead of entirely to achieve a good balance. So using
>the IGP instead is just a short-lived band-aid.
>
I basically agree with this. It is a short-lived band-aid. But it is a band-aid that covers a genuine wound, and only costs $5.
It would be better that there be no wound at all, but as it is it's an ok deal.
>I'm happy for you your setup gives you a pracical advantage for the current reality,
>but it's not a long-term argument pro IGPs.
>
>>More importantly it's a backup in case the Geforce dies. Which in fact, it did.
>>So now I use the IGP. If not for the IGP, the system would be unbootable until
>>I got a replacement GPU, which for laptops is a huge pain.
>>Am I glad I spent the extra $5 to get an IGP? Hell yes!
>
>With all due respect that's just a silly argument. It only shows how unreliable
>GPUs really are. Would you buy a car that comes with a free bike, "in case it breaks
>down"? Personally I'd rather buy from a manufacturer who gives me a higher quality
>guarantee. And note this 'bike' isn't actually free.
>
The relative prices and values matter here.
If I buy a known unreliable sports car on account of its speed and general awesomeness, and for just $5 extra, the dealer throws in a perfectly good motorcycle, I'd say that's a good deal.
Well, maybe buying an unreliable sports car at all is not a good deal, but in this case, the options are sorta limited, as all other cars on this market have problems at least equally bad.
With desktops, if your GPU dies, you can just buy a new video card swap it in.
With a laptop, if you GPU dies and you have no IGP, the entire system is pretty much dead, and the only way to fix it is to send it to the manufacturer who hopefully has the spare part.
I think a backup is worth at least $5.
>Seriously, IGP+GPU systems have no future.
>
>>>>Non-consumers are different, as they have non-graphics servers, and non-graphics workstations.
>>>>But there are separate processor lines for servers and whatnot, so they don't really count here.
>>>
>>>It does count for something because designing an IGP has a high R&D cost. In other
>>>words a 6-core CPU can be cheaper than a 4-core CPU + IGP even if the die size is
>>>exactly the same. Furthermore, having different production lines and testing methods
>>>and all that reduces the efficiency so not having to produce CPUs with an IGP not
>>>only saves R&D but also production cost.
>>
>>Having multiple products is necessary anyway (2-core netbook vs. 4-core laptop
>>vs. 6-core workstation vs. 8-core server)
>>The R&D cost can't be reduced unless they completely eliminate all IGPs from their
>entire product line, including Atom.
>
>Yes, multiple products remain necessary, but not another combination of CPUs with
>and without IGP. Reducing the number of product lines, reduces cost per part.
>
>And you appear to imply that Atom uses the same IGP design as Sandy Bridge.
No, what I'm saying is that they are spawned from different generations of the same product lines made by the same hardware design team.
Intel's current netbook IGPs are based on the previous generations of mainstream IGPs.
All of intel's future netbook IGPs will be based on hand-me-down designs of current and future mainstream IGPs.
So, most of the work gets done once, and is shared over time between the two product lines.
If you shut down the mainstream IGP development, you would also lose your netbook IGP development. It's one and the same.
If you keep the netbook IGP development going at all, then you still pay the full development price that you would have paid for both whether you use it twice or not.
So any plan to replace mainstream IGPs with software rendering is workable only if it also works for netbooks.
When do you expect netbooks to have 8+ cores & gather/scatter support?
Right now Atom doesn't even have a dual ported LSU, and most netbooks are still single-core+HT.
They've got a long way to go to catch up with even the terrible IGP they come with.
> That's
>incorrect. Pineview has a GMA 3150, which is the old Direct3D 9 generation GMA 3100
>shrunk to 45 nm. It does vertex processing in software! If all desktop CPUs eliminate
>the IGP and several years later Atom runs out of IGPs to shrink down, Intel can
>still license cheap IGPs from PowerVR. The cost is lower than designing such an
One problem here is that PowerVR IGP drivers are from hell, and any possible fix seems to be blocked by licensing issues that Intel has little control over.
The other problem is having a PowerVR IGP means having an IGP at all, which is what you are arguing against in the first place, isn't it?
Surely if there is cost savings to be had, the netbook market is the ideal place for it.
>IGP in-house since the PowerVR design is licensed to multiple manufacturers. And
>it's definitely cheaper than continuing to design IGPs suited for the desktop market.
>
>So once again ditching the IGP saves money, which translates into more valuable homogenous CPUs for everyone.
>
>Regards,
>
>Nicolas
Topic | Posted By | Date |
---|---|---|
Sandy Bridge CPU article online | David Kanter | 2010/09/26 09:35 PM |
Sandy Bridge CPU article online | Alex | 2010/09/27 05:22 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 10:06 AM |
Sandy Bridge CPU article online | someone | 2010/09/27 06:03 AM |
Sandy Bridge CPU article online | slacker | 2010/09/27 02:08 PM |
PowerPC is now Power | Paul A. Clayton | 2010/09/27 04:34 PM |
Sandy Bridge CPU article online | Dave | 2010/11/10 10:15 PM |
Sandy Bridge CPU article online | someone | 2010/09/27 06:23 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 06:39 PM |
Optimizing register clear | Paul A. Clayton | 2010/09/28 12:34 PM |
Sandy Bridge CPU article online | MS | 2010/09/27 06:54 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 10:15 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 11:02 AM |
Sandy Bridge CPU article online | mpx | 2010/09/27 11:44 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 02:37 PM |
Precisely | David Kanter | 2010/09/27 03:22 PM |
Sandy Bridge CPU article online | Richard Cownie | 2010/09/27 08:27 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 10:01 AM |
Sandy Bridge CPU article online | Richard Cownie | 2010/09/27 10:40 AM |
Sandy Bridge CPU article online | boots | 2010/09/27 11:19 AM |
Right, mid-2011, not 2010. Sorry (NT) | Richard Cownie | 2010/09/27 11:42 AM |
bulldozer single thread performance | Max | 2010/09/27 12:57 PM |
bulldozer single thread performance | Matt Waldhauer | 2011/03/02 11:32 AM |
Sandy Bridge CPU article online | Pun Zu | 2010/09/27 11:32 AM |
Sandy Bridge CPU article online | ? | 2010/09/27 11:44 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 01:11 PM |
My opinion is that anything that would take advantage of 256-bit AVX | redpriest | 2010/09/27 01:17 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/27 03:09 PM |
My opinion is that anything that would take advantage of 256-bit AVX | redpriest | 2010/09/27 04:06 PM |
My opinion is that anything that would take advantage of 256-bit AVX | David Kanter | 2010/09/27 05:23 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:57 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 04:35 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Matt Waldhauer | 2010/09/28 10:58 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/27 06:39 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 04:14 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Megol | 2010/09/28 02:17 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Michael S | 2010/09/28 05:47 AM |
PGI | Carlie Coats | 2010/09/28 10:23 AM |
gfortran... | Carlie Coats | 2010/09/29 09:33 AM |
My opinion is that anything that would take advantage of 256-bit AVX | mpx | 2010/09/28 12:58 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Michael S | 2010/09/28 01:36 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Foo_ | 2010/09/29 01:08 AM |
My opinion is that anything that would take advantage of 256-bit AVX | mpx | 2010/09/28 11:37 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/28 01:19 PM |
My opinion is that anything that would take advantage of 256-bit AVX | hobold | 2010/09/28 03:08 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 04:26 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Anthony | 2010/09/28 10:31 PM |
Sandy Bridge CPU article online | Hans de Vries | 2010/09/27 02:19 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 03:19 PM |
Sandy Bridge CPU article online | -Sweeper_ | 2010/09/27 05:50 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 06:41 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/27 02:55 PM |
Sandy Bridge CPU article online | line98 | 2010/09/27 03:05 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 03:20 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/27 03:23 PM |
Sandy Bridge CPU article online | line98 | 2010/09/27 03:42 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:33 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 04:04 PM |
Sandy Bridge CPU article online | Jack | 2010/09/27 04:40 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 11:47 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 11:54 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 11:59 PM |
Sandy Bridge CPU article online | JS | 2010/09/28 01:18 AM |
Sandy Bridge CPU article online | Royi | 2010/09/28 01:31 AM |
Sandy Bridge CPU article online | Jack | 2010/09/28 06:34 AM |
Sandy Bridge CPU article online | Royi | 2010/09/28 08:22 AM |
Sandy Bridge CPU article online | Foo_ | 2010/09/28 12:53 PM |
Sandy Bridge CPU article online | Paul | 2010/09/28 01:17 PM |
Sandy Bridge CPU article online | mpx | 2010/09/28 01:22 PM |
Sandy Bridge CPU article online | anonymous | 2010/09/28 02:06 PM |
Sandy Bridge CPU article online | IntelUser2000 | 2010/09/29 01:49 AM |
Sandy Bridge CPU article online | Jack | 2010/09/28 05:08 PM |
Sandy Bridge CPU article online | mpx | 2010/09/29 01:50 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/29 12:01 PM |
Sandy Bridge CPU article online | Royi | 2010/09/29 12:48 PM |
Sandy Bridge CPU article online | mpx | 2010/09/29 02:15 PM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/29 02:27 PM |
Sandy Bridge CPU article online | ? | 2010/09/29 11:18 PM |
Sandy Bridge CPU article online | savantu | 2010/09/30 12:28 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 03:43 AM |
Sandy Bridge CPU article online | gallier2 | 2010/09/30 04:18 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 08:38 AM |
Sandy Bridge CPU article online | David Hess | 2010/09/30 10:28 AM |
moderation (again) | hobold | 2010/10/01 05:08 AM |
Sandy Bridge CPU article online | Megol | 2010/09/30 02:13 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 03:47 AM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 08:54 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 10:18 AM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 12:04 PM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 12:38 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/30 01:02 PM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 08:09 PM |
Sandy Bridge CPU article online | mpx | 2010/09/30 12:40 PM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 01:00 PM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 08:44 PM |
Sandy Bridge CPU article online | David Hess | 2010/09/30 10:36 AM |
Sandy Bridge CPU article online | someone | 2010/09/30 11:23 AM |
Sandy Bridge CPU article online | mpx | 2010/09/30 01:50 PM |
wii lesson | Michael S | 2010/09/30 02:12 PM |
wii lesson | Dan Downs | 2010/09/30 03:33 PM |
wii lesson | Kevin G | 2010/10/01 12:27 AM |
wii lesson | Rohit | 2010/10/01 07:53 AM |
wii lesson | Kevin G | 2010/10/02 03:30 AM |
wii lesson | mpx | 2010/10/01 09:02 AM |
wii lesson | IntelUser2000 | 2010/10/01 09:31 AM |
GPUs and games | David Kanter | 2010/09/30 08:17 PM |
GPUs and games | hobold | 2010/10/01 05:27 AM |
GPUs and games | anonymous | 2010/10/01 06:35 AM |
GPUs and games | Gabriele Svelto | 2010/10/01 09:07 AM |
GPUs and games | Linus Torvalds | 2010/10/01 10:41 AM |
GPUs and games | Anon | 2010/10/01 11:23 AM |
Can Intel do *this* ??? | Mark Roulo | 2010/10/03 03:17 PM |
Can Intel do *this* ??? | Anon | 2010/10/03 03:29 PM |
Can Intel do *this* ??? | Mark Roulo | 2010/10/03 03:55 PM |
Can Intel do *this* ??? | Anon | 2010/10/03 05:45 PM |
Can Intel do *this* ??? | Ian Ameline | 2010/10/03 10:35 PM |
Graphics, IGPs, and Cache | Joe | 2010/10/10 09:51 AM |
Graphics, IGPs, and Cache | Anon | 2010/10/10 10:18 PM |
Graphics, IGPs, and Cache | Rohit | 2010/10/11 06:14 AM |
Graphics, IGPs, and Cache | hobold | 2010/10/11 06:43 AM |
Maybe the IGPU doesn't load into the L3 | Mark Roulo | 2010/10/11 08:05 AM |
Graphics, IGPs, and Cache | David Kanter | 2010/10/11 09:01 AM |
Can Intel do *this* ??? | Gabriele Svelto | 2010/10/04 12:31 AM |
Kanter's Law. | Ian Ameline | 2010/10/01 02:05 PM |
Kanter's Law. | David Kanter | 2010/10/01 02:18 PM |
Kanter's Law. | Ian Ameline | 2010/10/01 02:33 PM |
Kanter's Law. | Kevin G | 2010/10/01 04:19 PM |
Kanter's Law. | IntelUser2000 | 2010/10/01 10:36 PM |
Kanter's Law. | Kevin G | 2010/10/02 03:15 AM |
Kanter's Law. | IntelUser2000 | 2010/10/02 02:35 PM |
Wii vs pc's | Rohit | 2010/10/01 07:34 PM |
Wii vs pc's | Gabriele Svelto | 2010/10/01 11:54 PM |
GPUs and games | mpx | 2010/10/02 11:30 AM |
GPUs and games | Foo_ | 2010/10/02 04:03 PM |
GPUs and games | mpx | 2010/10/03 11:29 AM |
GPUs and games | Foo_ | 2010/10/03 01:52 PM |
GPUs and games | mpx | 2010/10/03 03:29 PM |
GPUs and games | Anon | 2010/10/03 03:49 PM |
GPUs and games | mpx | 2010/10/04 11:42 AM |
GPUs and games | MS | 2010/10/04 02:51 PM |
GPUs and games | Anon | 2010/10/04 08:29 PM |
persistence of vision | hobold | 2010/10/04 11:47 PM |
GPUs and games | mpx | 2010/10/05 12:51 AM |
GPUs and games | MS | 2010/10/05 06:49 AM |
GPUs and games | Jack | 2010/10/05 11:17 AM |
GPUs and games | MS | 2010/10/05 05:19 PM |
GPUs and games | Jack | 2010/10/05 11:11 AM |
GPUs and games | mpx | 2010/10/05 12:51 PM |
GPUs and games | David Kanter | 2010/10/06 09:04 AM |
GPUs and games | jack | 2010/10/06 09:34 PM |
GPUs and games | Linus Torvalds | 2010/10/05 07:29 AM |
GPUs and games | Foo_ | 2010/10/04 04:49 AM |
GPUs and games | Jeremiah | 2010/10/08 10:58 AM |
GPUs and games | MS | 2010/10/08 01:37 PM |
GPUs and games | Salvatore De Dominicis | 2010/10/04 01:41 AM |
GPUs and games | Kevin G | 2010/10/05 02:13 PM |
GPUs and games | mpx | 2010/10/03 11:36 AM |
GPUs and games | David Kanter | 2010/10/04 07:08 AM |
GPUs and games | Kevin G | 2010/10/04 10:38 AM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 09:19 PM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 12:06 PM |
Sandy Bridge CPU article online | rwessel | 2010/09/30 02:29 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/30 03:06 PM |
Sandy Bridge CPU article online | rwessel | 2010/09/30 06:55 PM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 03:53 AM |
Sandy Bridge CPU article online | rwessel | 2010/10/01 08:30 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 09:31 AM |
Sandy Bridge CPU article online | rwessel | 2010/10/01 10:56 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 08:28 PM |
Sandy Bridge CPU article online | Ricardo B | 2010/10/02 05:38 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/02 06:59 PM |
which bus more wasteful | Michael S | 2010/10/02 10:38 AM |
which bus more wasteful | rwessel | 2010/10/02 07:15 PM |
Sandy Bridge CPU article online | Ricardo B | 2010/10/01 10:08 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 08:31 PM |
Sandy Bridge CPU article online | Andi Kleen | 2010/10/01 11:55 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 08:32 PM |
Sandy Bridge CPU article online | kdg | 2010/10/01 11:26 AM |
Sandy Bridge CPU article online | Anon | 2010/10/01 11:33 AM |
Analog display out? | David Kanter | 2010/10/01 01:05 PM |
Analog display out? | mpx | 2010/10/02 11:46 AM |
Analog display out? | Anon | 2010/10/03 03:26 PM |
Digital is expensive! | David Kanter | 2010/10/03 06:36 PM |
Digital is expensive! | Anon | 2010/10/03 08:07 PM |
Digital is expensive! | David Kanter | 2010/10/03 10:02 PM |
Digital is expensive! | Steve Underwood | 2010/10/04 03:52 AM |
Digital is expensive! | David Kanter | 2010/10/04 07:03 AM |
Digital is expensive! | anonymous | 2010/10/04 07:11 AM |
Digital is not very expensive! | Steve Underwood | 2010/10/04 06:08 PM |
Digital is not very expensive! | Anon | 2010/10/04 08:33 PM |
Digital is not very expensive! | Steve Underwood | 2010/10/04 11:03 PM |
Digital is not very expensive! | mpx | 2010/10/05 01:10 PM |
Digital is not very expensive! | Gabriele Svelto | 2010/10/05 12:24 AM |
Digital is expensive! | jal142 | 2010/10/04 11:46 AM |
Digital is expensive! | mpx | 2010/10/04 01:04 AM |
Digital is expensive! | Gabriele Svelto | 2010/10/04 03:28 AM |
Digital is expensive! | Mark Christiansen | 2010/10/04 03:12 PM |
Analog display out? | slacker | 2010/10/03 06:44 PM |
Analog display out? | Anon | 2010/10/03 08:05 PM |
Analog display out? | Steve Underwood | 2010/10/04 03:48 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 08:37 PM |
Sandy Bridge CPU article online | slacker | 2010/10/02 02:53 PM |
Sandy Bridge CPU article online | David Hess | 2010/10/02 06:49 PM |
memory bandwith | Max | 2010/09/30 12:19 PM |
memory bandwith | Anon | 2010/10/01 11:28 AM |
memory bandwith | Jack | 2010/10/01 07:45 PM |
memory bandwith | Anon | 2010/10/03 03:19 PM |
Sandy Bridge CPU article online | PiedPiper | 2010/09/30 07:05 PM |
Sandy Bridge CPU article online | Matt Sayler | 2010/09/29 04:38 PM |
Sandy Bridge CPU article online | Jack | 2010/09/29 09:39 PM |
Sandy Bridge CPU article online | mpx | 2010/09/30 12:24 AM |
Sandy Bridge CPU article online | passer | 2010/09/30 03:15 AM |
Sandy Bridge CPU article online | mpx | 2010/09/30 03:47 AM |
Sandy Bridge CPU article online | passer | 2010/09/30 04:25 AM |
SB and web browsing | Rohit | 2010/09/30 06:47 AM |
SB and web browsing | David Hess | 2010/09/30 07:10 AM |
SB and web browsing | MS | 2010/09/30 10:21 AM |
SB and web browsing | passer | 2010/09/30 10:26 AM |
SB and web browsing | MS | 2010/10/02 06:41 PM |
SB and web browsing | Rohit | 2010/10/01 08:02 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/30 08:35 AM |
Sandy Bridge CPU article online | Jack | 2010/09/30 10:40 PM |
processor evolution | hobold | 2010/09/29 02:16 PM |
processor evolution | Foo_ | 2010/09/30 06:10 AM |
processor evolution | Jack | 2010/09/30 07:07 PM |
3D gaming as GPGPU app | hobold | 2010/10/01 04:59 AM |
3D gaming as GPGPU app | Jack | 2010/10/01 07:39 PM |
processor evolution | hobold | 2010/10/01 04:35 AM |
processor evolution | David Kanter | 2010/10/01 10:02 AM |
processor evolution | Anon | 2010/10/01 11:46 AM |
Display | David Kanter | 2010/10/01 01:26 PM |
Display | Rohit | 2010/10/02 02:56 AM |
Display | Linus Torvalds | 2010/10/02 07:40 AM |
Display | rwessel | 2010/10/02 08:58 AM |
Display | sJ | 2010/10/02 10:28 PM |
Display | rwessel | 2010/10/03 08:38 AM |
Display | Anon | 2010/10/03 03:06 PM |
Display tech and compute are different | David Kanter | 2010/10/03 06:33 PM |
Display tech and compute are different | Anon | 2010/10/03 08:16 PM |
Display tech and compute are different | David Kanter | 2010/10/03 10:00 PM |
Display tech and compute are different | hobold | 2010/10/04 01:40 AM |
Display | ? | 2010/10/03 03:02 AM |
Display | Linus Torvalds | 2010/10/03 10:18 AM |
Display | Richard Cownie | 2010/10/03 11:12 AM |
Display | Linus Torvalds | 2010/10/03 12:16 PM |
Display | slacker | 2010/10/03 07:35 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/04 07:06 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/04 11:44 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/04 02:59 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/04 03:13 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/04 08:58 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/05 01:39 AM |
current V12 engines with >6.0 displacement | MS | 2010/10/05 06:57 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/05 01:20 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/05 09:26 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 05:39 AM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 01:22 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/06 03:07 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 03:56 PM |
current V12 engines with >6.0 displacement | rwessel | 2010/10/06 03:30 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 03:53 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/07 01:32 PM |
current V12 engines with >6.0 displacement | rwessel | 2010/10/07 07:54 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 09:02 PM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | slacker | 2010/10/06 07:20 PM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | Ricardo B | 2010/10/07 01:32 AM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | slacker | 2010/10/07 08:15 AM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | Ricardo B | 2010/10/07 10:51 AM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 05:03 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 06:26 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 11:15 PM |
current V12 engines with >6.0 displacement | Howard Chu | 2010/10/07 02:16 PM |
current V12 engines with >6.0 displacement | Anon | 2010/10/05 10:31 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 05:55 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/06 06:15 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 06:34 AM |
I wonder is there any tech area that this forum doesn't have an opinion on (NT) | Rob Thorpe | 2010/10/06 10:11 AM |
Cunieform tablets | David Kanter | 2010/10/06 12:57 PM |
Cunieform tablets | Linus Torvalds | 2010/10/06 01:06 PM |
Ouch...maybe I should hire a new editor (NT) | David Kanter | 2010/10/06 04:38 PM |
Cunieform tablets | rwessel | 2010/10/06 03:41 PM |
Cunieform tablets | seni | 2010/10/07 10:56 AM |
Cunieform tablets | Howard Chu | 2010/10/07 01:44 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/06 06:10 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/06 10:44 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 07:55 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 08:51 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 07:38 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 08:33 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 09:04 PM |
Practical vehicles for commuting | Rob Thorpe | 2010/10/08 05:50 AM |
Practical vehicles for commuting | Gabriele Svelto | 2010/10/08 06:05 AM |
Practical vehicles for commuting | Rob Thorpe | 2010/10/08 06:21 AM |
Practical vehicles for commuting | j | 2010/10/08 02:20 PM |
Practical vehicles for commuting | Rob Thorpe | 2010/12/09 07:00 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/08 10:14 AM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/07 01:23 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/07 04:08 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 05:41 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 08:05 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 08:52 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/08 07:52 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 11:28 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 12:37 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/07 01:37 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/05 02:02 AM |
Display | Linus Torvalds | 2010/10/04 10:39 AM |
Display | Gabriele Svelto | 2010/10/05 12:34 AM |
Display | Richard Cownie | 2010/10/04 06:22 AM |
Display | anon | 2010/10/04 09:22 PM |
Display | Richard Cownie | 2010/10/05 06:42 AM |
Display | mpx | 2010/10/03 11:55 AM |
Display | rcf | 2010/10/03 01:12 PM |
Display | mpx | 2010/10/03 02:36 PM |
Display | rcf | 2010/10/03 05:36 PM |
Display | Ricardo B | 2010/10/04 02:50 PM |
Display | gallier2 | 2010/10/05 03:44 AM |
Display | David Hess | 2010/10/05 05:21 AM |
Display | gallier2 | 2010/10/05 08:21 AM |
Display | David Hess | 2010/10/03 11:21 PM |
Display | rcf | 2010/10/04 08:06 AM |
Display | David Kanter | 2010/10/03 01:54 PM |
Alternative integration | Paul A. Clayton | 2010/10/06 08:51 AM |
Display | slacker | 2010/10/03 07:26 PM |
Display & marketing & analogies | ? | 2010/10/04 02:33 AM |
Display & marketing & analogies | kdg | 2010/10/04 06:00 AM |
Display | Kevin G | 2010/10/02 09:49 AM |
Display | Anon | 2010/10/03 03:43 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/29 03:17 PM |
Sandy Bridge CPU article online | Jack | 2010/09/28 06:27 AM |
Sandy Bridge CPU article online | IntelUser2000 | 2010/09/28 03:07 AM |
Sandy Bridge CPU article online | mpx | 2010/09/28 12:34 PM |
Sandy Bridge CPU article online | Aaron Spink | 2010/09/28 01:28 PM |
Sandy Bridge CPU article online | JoshW | 2010/09/28 02:13 PM |
Sandy Bridge CPU article online | mpx | 2010/09/28 02:54 PM |
Sandy Bridge CPU article online | Foo_ | 2010/09/29 01:19 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 03:06 AM |
Sandy Bridge CPU article online | JS | 2010/09/29 03:42 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 04:03 AM |
Sandy Bridge CPU article online | Foo_ | 2010/09/29 05:55 AM |
Sandy Bridge CPU article online | ajensen | 2010/09/28 12:19 AM |
Sandy Bridge CPU article online | Ian Ollmann | 2010/09/28 04:52 PM |
Sandy Bridge CPU article online | a reader | 2010/09/28 05:05 PM |
Sandy Bridge CPU article online | ajensen | 2010/09/28 11:35 PM |
Updated: Sandy Bridge CPU article | David Kanter | 2010/10/01 05:11 AM |
Updated: Sandy Bridge CPU article | anon | 2011/01/07 09:55 PM |
Updated: Sandy Bridge CPU article | Eric Bron | 2011/01/08 03:29 AM |
Updated: Sandy Bridge CPU article | anon | 2011/01/11 11:24 PM |
Updated: Sandy Bridge CPU article | anon | 2011/01/15 11:21 AM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anon | 2011/01/16 11:22 PM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anonymous | 2011/01/17 02:04 AM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anon | 2011/01/17 07:12 AM |
I can try.... | David Kanter | 2011/01/18 03:54 PM |
I can try.... | anon | 2011/01/18 08:07 PM |
I can try.... | David Kanter | 2011/01/18 11:24 PM |
I can try.... | anon | 2011/01/19 07:51 AM |
Wider fetch than execute makes sense | Paul A. Clayton | 2011/01/19 08:53 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/04 07:29 AM |
Sandy Bridge CPU article online | Seni | 2011/01/04 09:07 PM |
Sandy Bridge CPU article online | hobold | 2011/01/04 11:26 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 02:01 AM |
software assist exceptions | hobold | 2011/01/05 04:36 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 01:58 AM |
Sandy Bridge CPU article online | anon | 2011/01/05 04:51 AM |
Sandy Bridge CPU article online | Seni | 2011/01/05 08:53 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 09:03 AM |
Sandy Bridge CPU article online | anon | 2011/01/05 04:14 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 04:50 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/05 05:00 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 07:26 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/05 07:50 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 08:39 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 03:50 PM |
permuting vector elements | hobold | 2011/01/05 05:03 PM |
permuting vector elements | Nicolas Capens | 2011/01/05 06:01 PM |
permuting vector elements | Nicolas Capens | 2011/01/06 08:27 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/11 11:33 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/11 01:51 PM |
Sandy Bridge CPU article online | hobold | 2011/01/11 02:11 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/11 06:07 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/12 03:25 AM |
Sandy Bridge CPU article online | hobold | 2011/01/12 05:03 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/12 11:27 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/13 02:38 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/13 03:32 AM |
Sandy Bridge CPU article online | hobold | 2011/01/13 01:53 PM |
What happened to VPERMIL2PS? | Michael S | 2011/01/13 03:46 AM |
What happened to VPERMIL2PS? | Eric Bron | 2011/01/13 06:46 AM |
Lower cost permute | Paul A. Clayton | 2011/01/13 12:11 PM |
Sandy Bridge CPU article online | anon | 2011/01/25 06:31 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/12 06:34 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/13 07:38 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/15 09:47 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/16 03:13 AM |
And just to make a further example | Gabriele Svelto | 2011/01/16 04:24 AM |
Sandy Bridge CPU article online | mpx | 2011/01/16 01:27 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/25 02:56 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/25 04:11 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/26 08:49 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/26 04:35 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/27 02:51 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/27 02:40 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/28 03:24 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/28 03:49 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/30 02:11 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/31 03:43 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/01 04:02 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/01 04:28 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/01 04:43 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/28 07:14 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/01 02:58 AM |
Sandy Bridge CPU article online | EduardoS | 2011/02/01 02:36 PM |
Sandy Bridge CPU article online | anon | 2011/02/01 04:56 PM |
Sandy Bridge CPU article online | EduardoS | 2011/02/01 09:17 PM |
Sandy Bridge CPU article online | anon | 2011/02/01 10:13 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/02 04:08 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/02 04:26 AM |
Sandy Bridge CPU article online | kalmaegi | 2011/02/01 09:29 AM |
SW Rasterization | David Kanter | 2011/01/27 05:18 PM |
Lower pin count memory | iz | 2011/01/27 09:19 PM |
Lower pin count memory | David Kanter | 2011/01/27 09:25 PM |
Lower pin count memory | iz | 2011/01/27 11:31 PM |
Lower pin count memory | David Kanter | 2011/01/27 11:52 PM |
Lower pin count memory | iz | 2011/01/28 12:28 AM |
Lower pin count memory | David Kanter | 2011/01/28 01:05 AM |
Lower pin count memory | iz | 2011/01/28 03:55 AM |
Lower pin count memory | David Hess | 2011/01/28 01:15 PM |
Lower pin count memory | David Kanter | 2011/01/28 01:57 PM |
Lower pin count memory | iz | 2011/01/28 05:20 PM |
Two years later | ForgotPants | 2013/10/26 11:33 AM |
Two years later | anon | 2013/10/26 11:36 AM |
Two years later | Exophase | 2013/10/26 12:56 PM |
Two years later | David Hess | 2013/10/26 05:05 PM |
Herz is totally the thing you DON*T care. | Jouni Osmala | 2013/10/27 01:48 AM |
Herz is totally the thing you DON*T care. | EduardoS | 2013/10/27 07:00 AM |
Herz is totally the thing you DON*T care. | Michael S | 2013/10/27 07:45 AM |
Two years later | someone | 2013/10/28 07:21 AM |
Lower pin count memory | Martin Høyer Kristiansen | 2011/01/28 01:41 AM |
Lower pin count memory | iz | 2011/01/28 03:07 AM |
Lower pin count memory | Darrell Coker | 2011/01/27 10:39 PM |
Lower pin count memory | iz | 2011/01/28 12:20 AM |
Lower pin count memory | Darrell Coker | 2011/01/28 06:07 PM |
Lower pin count memory | iz | 2011/01/28 11:57 PM |
Lower pin count memory | Darrell Coker | 2011/01/29 02:21 AM |
Lower pin count memory | iz | 2011/01/31 10:28 PM |
SW Rasterization | Nicolas Capens | 2011/02/02 08:48 AM |
SW Rasterization | Eric Bron | 2011/02/02 09:37 AM |
SW Rasterization | Nicolas Capens | 2011/02/02 04:35 PM |
SW Rasterization | Eric Bron | 2011/02/02 05:11 PM |
SW Rasterization | Eric Bron | 2011/02/03 02:13 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 07:57 AM |
SW Rasterization | Eric Bron | 2011/02/04 08:50 AM |
erratum | Eric Bron | 2011/02/04 08:58 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 05:25 PM |
SW Rasterization | David Kanter | 2011/02/04 05:33 PM |
SW Rasterization | anon | 2011/02/04 06:04 PM |
SW Rasterization | Nicolas Capens | 2011/02/05 03:39 PM |
SW Rasterization | David Kanter | 2011/02/05 05:07 PM |
SW Rasterization | Nicolas Capens | 2011/02/05 11:39 PM |
SW Rasterization | Eric Bron | 2011/02/04 10:55 AM |
Comments pt 1 | David Kanter | 2011/02/02 01:08 PM |
Comments pt 1 | Eric Bron | 2011/02/02 03:16 PM |
Comments pt 1 | Gabriele Svelto | 2011/02/03 01:37 AM |
Comments pt 1 | Eric Bron | 2011/02/03 02:36 AM |
Comments pt 1 | Nicolas Capens | 2011/02/03 11:08 PM |
Comments pt 1 | Nicolas Capens | 2011/02/03 10:26 PM |
Comments pt 1 | Eric Bron | 2011/02/04 03:33 AM |
Comments pt 1 | Nicolas Capens | 2011/02/04 05:24 AM |
example code | Eric Bron | 2011/02/04 04:51 AM |
example code | Nicolas Capens | 2011/02/04 08:24 AM |
example code | Eric Bron | 2011/02/04 08:36 AM |
example code | Nicolas Capens | 2011/02/05 11:43 PM |
Comments pt 1 | Rohit | 2011/02/04 12:43 PM |
Comments pt 1 | Nicolas Capens | 2011/02/04 05:05 PM |
Comments pt 1 | David Kanter | 2011/02/04 05:36 PM |
Comments pt 1 | Nicolas Capens | 2011/02/05 02:45 PM |
Comments pt 1 | Eric Bron | 2011/02/05 04:13 PM |
Comments pt 1 | Nicolas Capens | 2011/02/05 11:52 PM |
Comments pt 1 | Eric Bron | 2011/02/06 01:31 AM |
Comments pt 1 | Nicolas Capens | 2011/02/06 04:06 PM |
Comments pt 1 | Eric Bron | 2011/02/07 03:12 AM |
The need for gather/scatter support | Nicolas Capens | 2011/02/10 10:07 AM |
The need for gather/scatter support | Eric Bron | 2011/02/11 03:11 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/13 03:39 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 07:46 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 07:48 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 09:32 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 10:07 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 09:00 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 07:49 AM |
Gather/scatter performance data | Eric Bron | 2011/02/15 02:23 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 05:06 PM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 07:52 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 09:43 AM |
SW Rasterization - a long way off | Rohit | 2011/02/02 01:17 PM |
SW Rasterization - a long way off | Nicolas Capens | 2011/02/04 03:59 AM |
CPU only rendering - a long way off | Rohit | 2011/02/04 11:52 AM |
CPU only rendering - a long way off | Nicolas Capens | 2011/02/04 07:15 PM |
CPU only rendering - a long way off | Rohit | 2011/02/05 02:00 AM |
CPU only rendering - a long way off | Nicolas Capens | 2011/02/05 09:45 PM |
CPU only rendering - a long way off | David Kanter | 2011/02/06 09:51 PM |
CPU only rendering - a long way off | Gian-Carlo Pascutto | 2011/02/07 12:22 AM |
Encryption | David Kanter | 2011/02/07 01:18 AM |
Encryption | Nicolas Capens | 2011/02/07 07:51 AM |
Encryption | David Kanter | 2011/02/07 11:50 AM |
Encryption | Nicolas Capens | 2011/02/08 10:26 AM |
CPUs are latency optimized | David Kanter | 2011/02/08 11:38 AM |
efficient compiler on an efficient GPU real today. | sJ | 2011/02/08 11:29 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/09 09:49 PM |
CPUs are latency optimized | Eric Bron | 2011/02/10 12:49 AM |
CPUs are latency optimized | Antti-Ville Tuunainen | 2011/02/10 06:16 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/10 07:04 AM |
CPUs are latency optimized | Eric Bron | 2011/02/10 07:48 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/10 01:31 PM |
CPUs are latency optimized | Eric Bron | 2011/02/11 02:43 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/11 07:31 AM |
CPUs are latency optimized | EduardoS | 2011/02/10 05:29 PM |
CPUs are latency optimized | Anon | 2011/02/10 06:40 PM |
CPUs are latency optimized | David Kanter | 2011/02/10 08:33 PM |
CPUs are latency optimized | EduardoS | 2011/02/11 02:18 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/11 05:56 AM |
CPUs are latency optimized | Rohit | 2011/02/11 07:33 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/14 02:19 AM |
CPUs are latency optimized | Eric Bron | 2011/02/14 03:23 AM |
CPUs are latency optimized | EduardoS | 2011/02/14 01:11 PM |
CPUs are latency optimized | David Kanter | 2011/02/11 02:45 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/15 05:22 AM |
CPUs are latency optimized | David Kanter | 2011/02/15 12:47 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/15 07:10 PM |
Have fun | David Kanter | 2011/02/15 10:04 PM |
Have fun | Nicolas Capens | 2011/02/17 03:59 AM |
Have fun | Brett | 2011/02/17 12:56 PM |
Have fun | Nicolas Capens | 2011/02/19 04:53 PM |
Have fun | Brett | 2011/02/20 06:08 PM |
Have fun | Brett | 2011/02/20 07:13 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/02/23 05:37 PM |
On-die storage to fight Amdahl | Brett | 2011/02/23 09:59 PM |
On-die storage to fight Amdahl | Brett | 2011/02/23 10:08 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/02/24 07:42 PM |
On-die storage to fight Amdahl | Rohit | 2011/02/25 11:02 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/03/09 06:53 PM |
On-die storage to fight Amdahl | Rohit | 2011/03/10 08:02 AM |
NVIDIA using tile based rendering? | Nathan Monson | 2011/03/11 07:58 PM |
NVIDIA using tile based rendering? | Rohit | 2011/03/12 04:29 AM |
NVIDIA using tile based rendering? | Nathan Monson | 2011/03/12 11:05 AM |
NVIDIA using tile based rendering? | Rohit | 2011/03/12 11:16 AM |
On-die storage to fight Amdahl | Brett | 2011/02/26 02:10 AM |
On-die storage to fight Amdahl | Nathan Monson | 2011/02/26 01:51 PM |
On-die storage to fight Amdahl | Brett | 2011/02/26 04:40 PM |
Convergence is inevitable | Nicolas Capens | 2011/03/09 08:22 PM |
Convergence is inevitable | Brett | 2011/03/09 10:59 PM |
Convergence is inevitable | Antti-Ville Tuunainen | 2011/03/10 03:34 PM |
Convergence is inevitable | Brett | 2011/03/10 09:39 PM |
Procedural texturing? | David Kanter | 2011/03/11 01:32 AM |
Procedural texturing? | hobold | 2011/03/11 03:59 AM |
Procedural texturing? | Dan Downs | 2011/03/11 09:28 AM |
Procedural texturing? | Mark Roulo | 2011/03/11 02:58 PM |
Procedural texturing? | Anon | 2011/03/11 06:11 PM |
Procedural texturing? | Nathan Monson | 2011/03/11 07:30 PM |
Procedural texturing? | Brett | 2011/03/15 07:45 AM |
Procedural texturing? | Seni | 2011/03/15 10:13 AM |
Procedural texturing? | Brett | 2011/03/15 11:45 AM |
Procedural texturing? | Seni | 2011/03/15 02:09 PM |
Procedural texturing? | Brett | 2011/03/11 10:02 PM |
Procedural texturing? | Brett | 2011/03/11 09:34 PM |
Procedural texturing? | Eric Bron | 2011/03/12 03:37 AM |
Convergence is inevitable | Jouni Osmala | 2011/03/09 11:28 PM |
Convergence is inevitable | Brett | 2011/04/05 05:08 PM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 05:23 AM |
Convergence is inevitable | none | 2011/04/07 07:03 AM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 10:34 AM |
Convergence is inevitable | anon | 2011/04/07 02:15 PM |
Convergence is inevitable | none | 2011/04/08 01:57 AM |
Convergence is inevitable | Brett | 2011/04/07 08:04 PM |
Convergence is inevitable | none | 2011/04/08 02:14 AM |
Gather implementation | David Kanter | 2011/04/08 12:01 PM |
RAM Latency | David Hess | 2011/04/07 08:22 AM |
RAM Latency | Brett | 2011/04/07 07:20 PM |
RAM Latency | Nicolas Capens | 2011/04/07 10:18 PM |
RAM Latency | Brett | 2011/04/08 05:33 AM |
RAM Latency | Nicolas Capens | 2011/04/10 02:23 PM |
RAM Latency | Rohit | 2011/04/08 06:57 AM |
RAM Latency | Nicolas Capens | 2011/04/10 01:23 PM |
RAM Latency | David Kanter | 2011/04/10 02:27 PM |
RAM Latency | Rohit | 2011/04/11 06:17 AM |
Convergence is inevitable | Eric Bron | 2011/04/07 09:46 AM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 09:50 PM |
Convergence is inevitable | Eric Bron | 2011/04/08 12:39 AM |
Flaws in PowerVR | Rohit | 2011/02/25 11:21 PM |
Flaws in PowerVR | Brett | 2011/02/26 12:37 AM |
Flaws in PowerVR | Paul | 2011/02/26 05:17 AM |
Have fun | David Kanter | 2011/02/18 12:52 PM |
Have fun | Michael S | 2011/02/19 12:12 PM |
Have fun | David Kanter | 2011/02/19 03:26 PM |
Have fun | Michael S | 2011/02/19 04:43 PM |
Have fun | anon | 2011/02/19 05:02 PM |
Have fun | Michael S | 2011/02/19 05:56 PM |
Have fun | anon | 2011/02/20 03:50 PM |
Have fun | EduardoS | 2011/02/20 02:44 PM |
Linear vs non-linear | EduardoS | 2011/02/20 02:55 PM |
Have fun | Michael S | 2011/02/20 04:19 PM |
Have fun | EduardoS | 2011/02/20 05:51 PM |
Have fun | Nicolas Capens | 2011/02/21 11:12 AM |
Have fun | Michael S | 2011/02/21 12:38 PM |
Have fun | Eric Bron | 2011/02/21 02:10 PM |
Have fun | Eric Bron | 2011/02/21 02:39 PM |
Have fun | Michael S | 2011/02/21 06:13 PM |
Have fun | Eric Bron | 2011/02/22 12:43 AM |
Have fun | Michael S | 2011/02/22 01:47 AM |
Have fun | Eric Bron | 2011/02/22 02:10 AM |
Have fun | Michael S | 2011/02/22 11:37 AM |
Have fun | anon | 2011/02/22 01:38 PM |
Have fun | EduardoS | 2011/02/22 03:49 PM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/23 06:37 PM |
Gather/scatter efficiency | anonymous | 2011/02/23 06:51 PM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/24 06:57 PM |
Gather/scatter efficiency | anonymous | 2011/02/24 07:16 PM |
Gather/scatter efficiency | Michael S | 2011/02/25 07:45 AM |
Gather implementation | David Kanter | 2011/02/25 05:34 PM |
Gather implementation | Michael S | 2011/02/26 10:40 AM |
Gather implementation | anon | 2011/02/26 11:52 AM |
Gather implementation | Michael S | 2011/02/26 12:16 PM |
Gather implementation | anon | 2011/02/26 11:22 PM |
Gather implementation | Michael S | 2011/02/27 07:23 AM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/28 03:14 PM |
Consider yourself ignored | David Kanter | 2011/02/22 01:05 AM |
one more anti-FMA flame. By me. | Michael S | 2011/02/16 07:40 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/16 08:30 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/16 09:15 AM |
one more anti-FMA flame. By me. | Nicolas Capens | 2011/02/17 06:27 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/17 07:42 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/17 05:46 PM |
Tarantula paper | Paul A. Clayton | 2011/02/18 12:38 AM |
Tarantula paper | Nicolas Capens | 2011/02/19 05:19 PM |
anti-FMA != anti-throughput or anti-SG | Eric Bron | 2011/02/18 01:48 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/20 03:46 PM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/20 05:00 PM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 04:05 AM |
Software pipelining on x86 | David Kanter | 2011/02/23 05:04 AM |
Software pipelining on x86 | JS | 2011/02/23 05:25 AM |
Software pipelining on x86 | Salvatore De Dominicis | 2011/02/23 08:37 AM |
Software pipelining on x86 | Jouni Osmala | 2011/02/23 09:10 AM |
Software pipelining on x86 | LeeMiller | 2011/02/23 10:07 PM |
Software pipelining on x86 | Nicolas Capens | 2011/02/24 03:17 PM |
Software pipelining on x86 | anonymous | 2011/02/24 07:04 PM |
Software pipelining on x86 | Nicolas Capens | 2011/02/28 09:27 AM |
Software pipelining on x86 | Antti-Ville Tuunainen | 2011/03/02 04:31 AM |
Software pipelining on x86 | Megol | 2011/03/02 12:55 PM |
Software pipelining on x86 | Geert Bosch | 2011/03/03 07:58 AM |
FMA benefits and latency predictions | David Kanter | 2011/02/25 05:14 PM |
FMA benefits and latency predictions | Antti-Ville Tuunainen | 2011/02/26 10:43 AM |
FMA benefits and latency predictions | Matt Waldhauer | 2011/02/27 06:42 AM |
FMA benefits and latency predictions | Nicolas Capens | 2011/03/09 06:11 PM |
FMA benefits and latency predictions | Rohit | 2011/03/10 08:11 AM |
FMA benefits and latency predictions | Eric Bron | 2011/03/10 09:30 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/23 05:19 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 07:50 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/23 10:37 AM |
FMA and beyond | Nicolas Capens | 2011/02/24 04:47 PM |
detour on terminology | hobold | 2011/02/24 07:08 PM |
detour on terminology | Nicolas Capens | 2011/02/28 02:24 PM |
detour on terminology | Eric Bron | 2011/03/01 02:38 AM |
detour on terminology | Michael S | 2011/03/01 05:03 AM |
detour on terminology | Eric Bron | 2011/03/01 05:39 AM |
detour on terminology | Michael S | 2011/03/01 08:33 AM |
detour on terminology | Eric Bron | 2011/03/01 09:34 AM |
erratum | Eric Bron | 2011/03/01 09:54 AM |
detour on terminology | Nicolas Capens | 2011/03/10 08:39 AM |
detour on terminology | Eric Bron | 2011/03/10 09:50 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 06:12 AM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 11:25 PM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/17 06:51 PM |
Tarantula vector unit well-integrated | Paul A. Clayton | 2011/02/18 12:38 AM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/19 02:17 PM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 02:09 AM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/20 09:55 AM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 01:39 PM |
anti-FMA != anti-throughput or anti-SG | EduardoS | 2011/02/20 02:35 PM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/21 08:12 AM |
anti-FMA != anti-throughput or anti-SG | anon | 2011/02/17 10:44 PM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/18 06:20 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/17 08:24 AM |
thanks | Michael S | 2011/02/17 04:56 PM |
CPUs are latency optimized | EduardoS | 2011/02/15 01:24 PM |
SwiftShader SNB test | Eric Bron | 2011/02/15 03:46 PM |
SwiftShader NHM test | Eric Bron | 2011/02/15 04:50 PM |
SwiftShader SNB test | Nicolas Capens | 2011/02/17 12:06 AM |
SwiftShader SNB test | Eric Bron | 2011/02/17 01:21 AM |
SwiftShader SNB test | Eric Bron | 2011/02/22 10:32 AM |
SwiftShader SNB test 2nd run | Eric Bron | 2011/02/22 10:51 AM |
SwiftShader SNB test 2nd run | Nicolas Capens | 2011/02/23 02:14 PM |
SwiftShader SNB test 2nd run | Eric Bron | 2011/02/23 02:42 PM |
Win7SP1 out but no AVX hype? | Michael S | 2011/02/24 03:14 AM |
Win7SP1 out but no AVX hype? | Eric Bron | 2011/02/24 03:39 AM |
CPUs are latency optimized | Eric Bron | 2011/02/15 08:02 AM |
CPUs are latency optimized | EduardoS | 2011/02/11 03:40 PM |
CPU only rendering - not a long way off | Nicolas Capens | 2011/02/07 06:45 AM |
CPU only rendering - not a long way off | David Kanter | 2011/02/07 12:09 PM |
CPU only rendering - not a long way off | anonymous | 2011/02/07 10:25 PM |
Sandy Bridge IGP EUs | David Kanter | 2011/02/07 11:22 PM |
Sandy Bridge IGP EUs | Hannes | 2011/02/08 05:59 AM |
SW Rasterization - Why? | Seni | 2011/02/02 02:53 PM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/10 03:12 PM |
Market reasons to ditch the IGP | Seni | 2011/02/11 05:42 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/16 04:29 AM |
Market reasons to ditch the IGP | Seni | 2011/02/16 01:39 PM |
An excellent post! | David Kanter | 2011/02/16 03:18 PM |
CPUs clock higher | Moritz | 2011/02/17 08:06 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/18 06:22 PM |
Market reasons to ditch the IGP | IntelUser2000 | 2011/02/18 07:20 PM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/21 02:42 PM |
Bad data (repeated) | David Kanter | 2011/02/22 12:21 AM |
Bad data (repeated) | none | 2011/02/22 03:04 AM |
13W or 8W? | Foo_ | 2011/02/22 06:00 AM |
13W or 8W? | Linus Torvalds | 2011/02/22 08:58 AM |
13W or 8W? | David Kanter | 2011/02/22 11:33 AM |
13W or 8W? | Mark Christiansen | 2011/02/22 02:47 PM |
Bigger picture | Nicolas Capens | 2011/02/24 06:33 PM |
Bigger picture | Nicolas Capens | 2011/02/24 08:06 PM |
20+ Watt | Nicolas Capens | 2011/02/24 08:18 PM |
<20W | David Kanter | 2011/02/25 01:13 PM |
>20W | Nicolas Capens | 2011/03/08 07:34 PM |
IGP is 3X more efficient | David Kanter | 2011/03/08 10:53 PM |
IGP is 3X more efficient | Eric Bron | 2011/03/09 02:44 AM |
>20W | Eric Bron | 2011/03/09 03:48 AM |
Specious data and claims are still specious | David Kanter | 2011/02/25 02:38 AM |
IGP power consumption, LRB samplers | Nicolas Capens | 2011/03/08 06:24 PM |
IGP power consumption, LRB samplers | EduardoS | 2011/03/08 06:52 PM |
IGP power consumption, LRB samplers | Rohit | 2011/03/09 07:42 AM |
Market reasons to ditch the IGP | none | 2011/02/22 02:58 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/24 06:43 PM |
Market reasons to ditch the IGP | slacker | 2011/02/22 02:32 PM |
Market reasons to ditch the IGP | Seni | 2011/02/18 09:51 PM |
Correction - 28 comparators, not 36. (NT) | Seni | 2011/02/18 10:03 PM |
Market reasons to ditch the IGP | Gabriele Svelto | 2011/02/19 01:49 AM |
Market reasons to ditch the IGP | Seni | 2011/02/19 11:59 AM |
Market reasons to ditch the IGP | Exophase | 2011/02/20 10:43 AM |
Market reasons to ditch the IGP | EduardoS | 2011/02/19 10:13 AM |
Market reasons to ditch the IGP | Seni | 2011/02/19 11:46 AM |
The next revolution | Nicolas Capens | 2011/02/22 03:33 AM |
The next revolution | Gabriele Svelto | 2011/02/22 09:15 AM |
The next revolution | Eric Bron | 2011/02/22 09:48 AM |
The next revolution | Nicolas Capens | 2011/02/23 07:39 PM |
The next revolution | Gabriele Svelto | 2011/02/24 12:43 AM |
GPGPU content creation (or lack of it) | Nicolas Capens | 2011/02/28 07:39 AM |
GPGPU content creation (or lack of it) | The market begs to differ | 2011/03/01 06:32 AM |
GPGPU content creation (or lack of it) | Nicolas Capens | 2011/03/09 09:14 PM |
GPGPU content creation (or lack of it) | Gabriele Svelto | 2011/03/10 01:01 AM |
The market begs to differ | Gabriele Svelto | 2011/03/01 06:33 AM |
The next revolution | Anon | 2011/02/24 02:15 AM |
The next revolution | Nicolas Capens | 2011/02/28 02:34 PM |
The next revolution | Seni | 2011/02/22 02:02 PM |
The next revolution | Gabriele Svelto | 2011/02/23 06:27 AM |
The next revolution | Seni | 2011/02/23 09:03 AM |
The next revolution | Nicolas Capens | 2011/02/24 06:11 AM |
The next revolution | Seni | 2011/02/24 08:45 PM |
IGP sampler count | Nicolas Capens | 2011/03/03 05:19 AM |
Latency and throughput optimized cores | Nicolas Capens | 2011/03/07 03:28 PM |
The real reason no IGP /CPU converge. | Jouni Osmala | 2011/03/07 11:34 PM |
Still converging | Nicolas Capens | 2011/03/13 03:08 PM |
Homogeneous CPU advantages | Nicolas Capens | 2011/03/08 12:12 AM |
Homogeneous CPU advantages | Seni | 2011/03/08 09:23 AM |
Homogeneous CPU advantages | David Kanter | 2011/03/08 11:16 AM |
Homogeneous CPU advantages | Brett | 2011/03/09 03:37 AM |
Homogeneous CPU advantages | Jouni Osmala | 2011/03/09 12:27 AM |
SW Rasterization | firsttimeposter | 2011/02/03 11:18 PM |
SW Rasterization | Nicolas Capens | 2011/02/04 04:48 AM |
SW Rasterization | Eric Bron | 2011/02/04 05:14 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 08:36 AM |
SW Rasterization | Eric Bron | 2011/02/04 08:42 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/26 03:23 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/02/04 04:31 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/05 08:46 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/02/06 06:20 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/06 06:07 PM |
Sandy Bridge CPU article online | arch.comp | 2011/01/06 10:58 PM |
Sandy Bridge CPU article online | Seni | 2011/01/07 10:25 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 04:28 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 06:06 AM |
permuting vector elements (yet again) | hobold | 2011/01/05 05:15 PM |
permuting vector elements (yet again) | Nicolas Capens | 2011/01/06 06:11 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/05 12:46 PM |
wow ...! | hobold | 2011/01/05 05:19 PM |
wow ...! | Nicolas Capens | 2011/01/05 06:11 PM |
wow ...! | Eric Bron | 2011/01/05 10:46 PM |
compress LUT | Eric Bron | 2011/01/05 11:05 PM |
wow ...! | Michael S | 2011/01/06 02:25 AM |
wow ...! | Nicolas Capens | 2011/01/06 06:26 AM |
wow ...! | Eric Bron | 2011/01/06 09:08 AM |
wow ...! | Nicolas Capens | 2011/01/07 07:19 AM |
wow ...! | Steve Underwood | 2011/01/07 10:53 PM |
saturation | hobold | 2011/01/08 10:25 AM |
saturation | Steve Underwood | 2011/01/08 12:38 PM |
saturation | Michael S | 2011/01/08 01:05 PM |
128 bit floats | Brett | 2011/01/08 01:39 PM |
128 bit floats | Michael S | 2011/01/08 02:10 PM |
128 bit floats | Anil Maliyekkel | 2011/01/08 03:46 PM |
128 bit floats | Kevin G | 2011/02/27 11:15 AM |
128 bit floats | hobold | 2011/02/27 04:42 PM |
128 bit floats | Ian Ollmann | 2011/02/28 04:56 PM |
OpenCL FP accuracy | hobold | 2011/03/01 06:45 AM |
OpenCL FP accuracy | anon | 2011/03/01 08:03 PM |
OpenCL FP accuracy | hobold | 2011/03/02 03:53 AM |
OpenCL FP accuracy | Eric Bron | 2011/03/02 07:10 AM |
pet project | hobold | 2011/03/02 09:22 AM |
pet project | Anon | 2011/03/02 09:10 PM |
pet project | hobold | 2011/03/03 04:57 AM |
pet project | Eric Bron | 2011/03/03 02:29 AM |
pet project | hobold | 2011/03/03 05:14 AM |
pet project | Eric Bron | 2011/03/03 03:10 PM |
pet project | hobold | 2011/03/03 04:04 PM |
OpenCL and AMD | Vincent Diepeveen | 2011/03/07 01:44 PM |
OpenCL and AMD | Eric Bron | 2011/03/08 02:05 AM |
OpenCL and AMD | Vincent Diepeveen | 2011/03/08 08:27 AM |
128 bit floats | Michael S | 2011/02/27 04:46 PM |
128 bit floats | Anil Maliyekkel | 2011/02/27 06:14 PM |
saturation | Steve Underwood | 2011/01/17 04:42 AM |
wow ...! | hobold | 2011/01/06 05:05 PM |
Ring | Moritz | 2011/01/20 10:51 PM |
Ring | Antti-Ville Tuunainen | 2011/01/21 12:25 PM |
Ring | Moritz | 2011/01/23 01:38 AM |
Ring | Michael S | 2011/01/23 04:04 AM |
So fast | Moritz | 2011/01/23 07:57 AM |
So fast | David Kanter | 2011/01/23 10:05 AM |
Sandy Bridge CPU (L1D cache) | Gordon Ward | 2011/09/09 02:47 AM |
Sandy Bridge CPU (L1D cache) | David Kanter | 2011/09/09 04:19 PM |
Sandy Bridge CPU (L1D cache) | EduardoS | 2011/09/09 08:53 PM |
Sandy Bridge CPU (L1D cache) | Paul A. Clayton | 2011/09/10 05:12 AM |
Sandy Bridge CPU (L1D cache) | Michael S | 2011/09/10 09:41 AM |
Sandy Bridge CPU (L1D cache) | EduardoS | 2011/09/10 11:17 AM |
Address Ports on Sandy Bridge Scheduler | Victor | 2011/10/16 06:40 AM |
Address Ports on Sandy Bridge Scheduler | EduardoS | 2011/10/16 07:45 PM |
Address Ports on Sandy Bridge Scheduler | Megol | 2011/10/17 09:20 AM |
Address Ports on Sandy Bridge Scheduler | Victor | 2011/10/18 05:34 PM |
Benefits of early scheduling | Paul A. Clayton | 2011/10/18 06:53 PM |
Benefits of early scheduling | Victor | 2011/10/19 05:58 PM |
Consistency and invalidation ordering | Paul A. Clayton | 2011/10/20 04:43 AM |
Address Ports on Sandy Bridge Scheduler | John Upcroft | 2011/10/21 04:16 PM |
Address Ports on Sandy Bridge Scheduler | David Kanter | 2011/10/22 10:49 AM |
Address Ports on Sandy Bridge Scheduler | John Upcroft | 2011/10/26 01:24 PM |
Store TLB look-up at commit? | Paul A. Clayton | 2011/10/26 08:30 PM |
Store TLB look-up at commit? | Richard Scott | 2011/10/26 09:40 PM |
Just a guess | Paul A. Clayton | 2011/10/27 01:54 PM |