By: Nicolas Capens (nicolas.capens.delete@this.gmail.com), February 21, 2011 10:12 am
Room: Moderated Discussions
Hi David,
David Kanter (dkanter@realworldtech.com) on 2/18/11 wrote:
---------------------------
>>>You don't understand anything I write, so I'm done discussing this with you.
>>
>>What exactly didn't I understand? That a high-end discrete GPU with almost three
>>times more transistors having nearly an order of magnitude higher bandwidth over
>>a CPU+IGP, really is relevant to the viability of having a >homogenous CPU take over the role of said IGP?
>
>No, you don't understand circuit design or any of the fundamental trade-offs that
>come into play when designing hardware (let alone the economics of selling such hardware).
That's your opinion. You haven't actually proven that I don't understand these things.
Let's try again. How is a high-end discrete GPU with almost three times more transistors having nearly an order of magnitude higher bandwidth over a CPU+IGP, relevant to the viability of a homogeneous CPU taking over the role of said IGP?
I'm an intelligent guy with a masters degree in computer engineering so if I'm ignorant about this matter I'm sure an analyst like you can explain it to me in glorious detail. Either that, or this order of magnitude difference is nowhere near as relevant as you're trying to imply.
>Not only that, but you consistently refuse to face reality and consider HARD metrics
>and data that is contrary to your beliefs.
The bandwidth of a discrete GPU is indeed a hard metric, but I don't refuse to face that and it's not contrary to my 'beliefs'. It's just utterly irrelevant to a homogenous CPU taking on the task of the IGP. Unless you have other hard metrics that prove software rendering would be bandwidth starved while the IGP is not?
>>Don't be ridiculous. You're done discussing because you >ran out of arguments. You
>>failed to look at the bigger picture and take the (triple) >convergence into account,
>>and you failed to take the benefits of unification into >account (*).
>
>You're certainly welcome to your near religious beliefs.
Don't try to turn the whole discussion into something personal. I've backed each of these arguments with evidence. I'll sum things up once more:
1) Convergence #1: CPUs will improve their compute density with FMA, and gather/scatter support improves effective throughput.
2) Convergence #2: GPUs will lose compute density because Amdahl's Law prevents linear performance scaling for the same workload. Investing into latency optimizations to prevent bottlenecks, and frequency optimizations to speed up sequential tasks, becomes ever more vital.
3) Convergence #3: The workload is shifting too. There's an increasing need for programmability and GPUs are expected to do more than classic rasterization alone. This forces them to spend less die area on throughput as well.
4) Unification: An IGP still needs a CPU so there's always one of them going to be partially idle. With a homogenous architecture you have the whole chip at your disposal.
All of these things help favor software rendering in the not too distant future. You can call them "religious" all you want, you haven't debunked any of them.
>>And that's forgivable. The current gap between the CPU and IGP can easily lead
>>one to disregard progress and believe CPUs can never adequately handle graphics.
>>But I expected you would at least have the decency to admit I might have a few valid
>>points about how that current situation will change in >favor of software rendering,
>>instead of saying I don't understand anything you write.
>
>I told you exactly when that would happen. When the % of CPU cycles required to
>do mainstream rendering* is <5% of the CPU cycles. That's what it took for us to get rid of sound hardware.
You're wrong. First of all, playing an MP3 on an AC'97 solution took up to 50% of CPU usage in the early years. This dropped as CPUs got faster, but then EAX and other tehnologies were introduced and it went up again. So for a considerable amount of time the CPU usage was well over 5% yet software audio processing quickly dominated the market.
Secondly, I've already shown you that gaming with an IGP takes relatively high power consumption as well: http://www.legionhardware.com/articles_pages/intel_core_i5_2500k_and_core_i7_2600k_sandy_bridge,14.html So a software rendering solution does not have to take less than 5% of CPU cycles to be viable.
>>That would be pretty terrible in and by itself. You're an >analyst so you're supposed
>>to explain things in a way people can easily understand >it. So either you failed
>>to make an engineer understand "anything" you wrote, or >some of the things you wrote are false or irrelevant.
>
>Unfortunately, when you are faced with someone who:
>1. Doesn't understand key relevant concepts
>2. Refuses to learn
>3. Cannot agree on basic and widely accepted metrics for comparing different approaches
>4. Constantly pushes for hypothetical scenarios with no data or evidence
>
>There's really not a lot to be done. I can't debate someone over beliefs that
>take on the nature of religious fervor and blind faith.
Again you're just deflecting technical matter into a personal attack. I might just as well say you don't understand key relevant concepts (or don't understand why some are or little or no relevance), you refuse to learn, you cannot agree on anything, and you constantly push for comparisons against products for distinct market segments. That doesn't advance the discussion since it's one professional's opinion against another. So I prefer to think you're an intelligent guy, who actually does understand the things I say and has the ability to explain in detail the things I might be wrong about (and explain how it's relevant to the bigger picture).
So stop demeaning yourself and wasting time by changing the subject from technical into personal. Even in the odd chance that I'm totally ignorant about all this, it's arrogant and rude to say I'm wrong and not take my arguments into account. Heck, if it was readily obvious to everyone that I'm wrong about everything, the right thing to do would be to just ignore me and let the future speak for itself, not try to insult me.
>>So I kindly suggest you do take another look at my previous response, and either
>>show how I misunderstood that big differences at the hardware level equally affect
>>software rendering efficiency of future CPUs, or start putting some doubt into your
>>premature conclusions. I believe we settled on using Crysis as a benchmark for effective
>>throughput, so don't give me theoretical data unless you also prove that it's significantly
>>relevant to the viability of a homogenous CPU doing >graphics.
>
>I already explained, at length, repeatedly. Others have explained as well.
Not really. Noone has explained how a latency optimized device with wide vectors and FMA can't possibly be throughput optimized as well. And given the unification benefit it doesn't need to have the same compute density to count as a throughput optimized device. And let's not forget the three convergence arguments which continue to move them closer together.
Furthermore, you nor anyone else has given me benchmark numbers for the IGP which indicate that the effective performance of a CPU with FMA and gather/scatter can't compete with that.
So stop saying you've "already explained, at length, repeatedly".
>For instance, we all asked how many gate delays, power and area would the hypothetical
>gather/scatter cost to implement. How would it impact single threaded code (e.g.
>SPECint). I have yet to hear anything.
This is the first time I've read anyone explicitly ask about gate delays. But okay; there would be zero extra gate delays. That's because selecting four elements from a cache line instead of one, can be done in parallel. Also, calculating which of the elements are located within the same cache line, and computing their offset, can be done in parallel as well and isn't actually needed till the cache line has already been fetched. Of course fan-in/out increases at some points but (progressive) transistor sizing and/or input reordering can deal with that if necessary. Note that even if I'm wrong about any of this, you'll still also have to prove that the required extra gate delays are actually significant. A contemporary CPU can do 64-bit adds in one cycle and the gate delay for that is between 30 to 60 inverters (and that's without counting other delays to perform back-to-back operations). Since the CPU's clock frequency is increasingly less aggressive you can expect the gate delay budget to go up with every process node.
Next, I already detailed somewhere that emulating gather/scatter takes 24 uops which each pass over 128 bits of data around, and starves some of the other logic so it consumes idle power. Dedicated gather/scatter support would not occupy any of the ALU pipelines, and keeps the data being moved around to a bare minimum. So it's a big win in terms of power.
As for the area requirement, the element selection isn't all that different from the permute units in the ALUs. Other than that four 25-bit comparators and four 7-bit adders are needed (per LSU) but as indicated these can be relatively slow (and thus quite compact). Logic to keep multiple misses in flight is already in place. Of course the exact area requirement is hard to determine but feel free to fill me in if you want to prove it's too expensive. Note that Cell BE has 8 high-frequency 2-cycle-latency independent load/store units at 241 million transistors (looking at just the SPEs), while Sandy Bridge has four times the transistor budget, so asking for 8 load/store units capable of 4-element gather/scatter doesn't seem like a big deal to me.
And I've already pointed you to a paper which indicate that SPECint would be able to benefit from gather/scatter by about 20% thanks to more succesful parallelization of loops. SPECfp obviously benefits even more. So even for non-graphics workloads the area investment is clearly well worth it.
>Moreover, you make utterly unsubstantiated (and simply wrong) claims about the
>applicability of gather/scatter to ordinary code and claims about performance implications
>for SW rendering WITHOUT any substantiation. How do you know that single cycle
>scatter/gather is achievable? You don't even know the number of gate delays required.
You wrongfully assumed I didn't know the gate delays, and clearly you didn't know yourself since otherwise you wouldn't have asked.
And I did substantiate the applicability by noting that texel fetch is essentially a gather operation, which currently takes many uops to emulate. Lookup tables for transcendental functions also fit in L1 cache lines so those operations benefit substantially as well. And that's just scratching the surface.
Furthermore, the 20% benefit for SPECint merely requires the use of the 'restrict' keyword to statically determine dependencies (instead of dynamically as done by the paper). Even if static analysis yields lower benefit, it's highly doubtful that the investment isn't worth it. If that's not enough substantiation for you, feel free to take the opportunity to prove me wrong. Simply saying I don't provide enough positive proof does not count as negative proof.
[snip]
>Moreover, the data you provided was simply WRONG and BAD and DISCREDITED by the
>author of the simulator you used. Merely presenting spurious data isn't helpful to the conversation.
First of all, you haven't given me any indication at all what's wrong about it, nor how wrong it really is. The texture bandwidth of contemporary games may just as well be less than what's shown in that old ATTILA graph. So merely telling me the data is wrong doesn't prove your claims at all.
Secondly, I *measured* the number of uncompressed texture accesses for Crysis, and *conservatively* determined that it does not have a significant impact on bandwidth.
>>(*) P.S.: Just in case you still don't see it, the benefit >of unification is that
>>a homogenous CPU does not need to have the same compute >density as the IGP, to exceed
>>its effective performance. You basically get area for >free, which would have otherwise
>>remained largely idle (and you can trade it for power).
>
>How do you know it would have remained idle?
On my system with a GTX 460 and 3.2 GHz Nehalem, the Crysis CPU benchmark peaks at only 27% of CPU cycles. The average CPU usage is lower, and clearly with an IGP limiting the framerate the CPU usage would be lower still.
So the vast majority of CPU cycles are left unused. You can't ignore the unification benefit when comparing compute density.
>I agree it would be nice to have
>a unified architecture, but I think the reality is that processing in general is
>going to trend towards two distinct resources: latency optimized and throughput
>optimized, driven by the fundamental power and area efficiencies for separating the two.
There's two things separating latency optimized and throughput optimized hardware: architecture and design. Architecture isn't much of an argument though, due to the unification benefits. A homogenous architecture would have lower theoretical compute density than a GPU but like I said before that's fine since you already paid for the architectural latency optimizations to make it function as a CPU. For instance a bypass network takes extra wires and control logic but you need those for the CPU functionality anyway *and* it reduces the necessary register file size and reduces cache trashing. So at the architecture level the latency optimizations don't have to cost you anything thanks to unification.
So we're left mainly with design level differences. An area optimized ALU can be substantially smaller than an aggressively latency optimized one, exceeding any effective architectural benefit from the lower latency. That said, the MHz-race is long behind us, and things continue to converge on no less than three fronts! At 32 nm, the CPU's latencies are not aggressive at all. There's insane overclocking potential (even on air) and I believe all dynamic logic is gone. So Intel is optimizing for area and power as well. By the time gather/scatter is added there will be very little difference between CPU logic and IGP logic. Your lantency comparisons indicating an order of magnitude difference are invalid since you haven't taken the bypass network into account nor the instruction complexity and other stages.
Cheers,
Nicolas
David Kanter (dkanter@realworldtech.com) on 2/18/11 wrote:
---------------------------
>>>You don't understand anything I write, so I'm done discussing this with you.
>>
>>What exactly didn't I understand? That a high-end discrete GPU with almost three
>>times more transistors having nearly an order of magnitude higher bandwidth over
>>a CPU+IGP, really is relevant to the viability of having a >homogenous CPU take over the role of said IGP?
>
>No, you don't understand circuit design or any of the fundamental trade-offs that
>come into play when designing hardware (let alone the economics of selling such hardware).
That's your opinion. You haven't actually proven that I don't understand these things.
Let's try again. How is a high-end discrete GPU with almost three times more transistors having nearly an order of magnitude higher bandwidth over a CPU+IGP, relevant to the viability of a homogeneous CPU taking over the role of said IGP?
I'm an intelligent guy with a masters degree in computer engineering so if I'm ignorant about this matter I'm sure an analyst like you can explain it to me in glorious detail. Either that, or this order of magnitude difference is nowhere near as relevant as you're trying to imply.
>Not only that, but you consistently refuse to face reality and consider HARD metrics
>and data that is contrary to your beliefs.
The bandwidth of a discrete GPU is indeed a hard metric, but I don't refuse to face that and it's not contrary to my 'beliefs'. It's just utterly irrelevant to a homogenous CPU taking on the task of the IGP. Unless you have other hard metrics that prove software rendering would be bandwidth starved while the IGP is not?
>>Don't be ridiculous. You're done discussing because you >ran out of arguments. You
>>failed to look at the bigger picture and take the (triple) >convergence into account,
>>and you failed to take the benefits of unification into >account (*).
>
>You're certainly welcome to your near religious beliefs.
Don't try to turn the whole discussion into something personal. I've backed each of these arguments with evidence. I'll sum things up once more:
1) Convergence #1: CPUs will improve their compute density with FMA, and gather/scatter support improves effective throughput.
2) Convergence #2: GPUs will lose compute density because Amdahl's Law prevents linear performance scaling for the same workload. Investing into latency optimizations to prevent bottlenecks, and frequency optimizations to speed up sequential tasks, becomes ever more vital.
3) Convergence #3: The workload is shifting too. There's an increasing need for programmability and GPUs are expected to do more than classic rasterization alone. This forces them to spend less die area on throughput as well.
4) Unification: An IGP still needs a CPU so there's always one of them going to be partially idle. With a homogenous architecture you have the whole chip at your disposal.
All of these things help favor software rendering in the not too distant future. You can call them "religious" all you want, you haven't debunked any of them.
>>And that's forgivable. The current gap between the CPU and IGP can easily lead
>>one to disregard progress and believe CPUs can never adequately handle graphics.
>>But I expected you would at least have the decency to admit I might have a few valid
>>points about how that current situation will change in >favor of software rendering,
>>instead of saying I don't understand anything you write.
>
>I told you exactly when that would happen. When the % of CPU cycles required to
>do mainstream rendering* is <5% of the CPU cycles. That's what it took for us to get rid of sound hardware.
You're wrong. First of all, playing an MP3 on an AC'97 solution took up to 50% of CPU usage in the early years. This dropped as CPUs got faster, but then EAX and other tehnologies were introduced and it went up again. So for a considerable amount of time the CPU usage was well over 5% yet software audio processing quickly dominated the market.
Secondly, I've already shown you that gaming with an IGP takes relatively high power consumption as well: http://www.legionhardware.com/articles_pages/intel_core_i5_2500k_and_core_i7_2600k_sandy_bridge,14.html So a software rendering solution does not have to take less than 5% of CPU cycles to be viable.
>>That would be pretty terrible in and by itself. You're an >analyst so you're supposed
>>to explain things in a way people can easily understand >it. So either you failed
>>to make an engineer understand "anything" you wrote, or >some of the things you wrote are false or irrelevant.
>
>Unfortunately, when you are faced with someone who:
>1. Doesn't understand key relevant concepts
>2. Refuses to learn
>3. Cannot agree on basic and widely accepted metrics for comparing different approaches
>4. Constantly pushes for hypothetical scenarios with no data or evidence
>
>There's really not a lot to be done. I can't debate someone over beliefs that
>take on the nature of religious fervor and blind faith.
Again you're just deflecting technical matter into a personal attack. I might just as well say you don't understand key relevant concepts (or don't understand why some are or little or no relevance), you refuse to learn, you cannot agree on anything, and you constantly push for comparisons against products for distinct market segments. That doesn't advance the discussion since it's one professional's opinion against another. So I prefer to think you're an intelligent guy, who actually does understand the things I say and has the ability to explain in detail the things I might be wrong about (and explain how it's relevant to the bigger picture).
So stop demeaning yourself and wasting time by changing the subject from technical into personal. Even in the odd chance that I'm totally ignorant about all this, it's arrogant and rude to say I'm wrong and not take my arguments into account. Heck, if it was readily obvious to everyone that I'm wrong about everything, the right thing to do would be to just ignore me and let the future speak for itself, not try to insult me.
>>So I kindly suggest you do take another look at my previous response, and either
>>show how I misunderstood that big differences at the hardware level equally affect
>>software rendering efficiency of future CPUs, or start putting some doubt into your
>>premature conclusions. I believe we settled on using Crysis as a benchmark for effective
>>throughput, so don't give me theoretical data unless you also prove that it's significantly
>>relevant to the viability of a homogenous CPU doing >graphics.
>
>I already explained, at length, repeatedly. Others have explained as well.
Not really. Noone has explained how a latency optimized device with wide vectors and FMA can't possibly be throughput optimized as well. And given the unification benefit it doesn't need to have the same compute density to count as a throughput optimized device. And let's not forget the three convergence arguments which continue to move them closer together.
Furthermore, you nor anyone else has given me benchmark numbers for the IGP which indicate that the effective performance of a CPU with FMA and gather/scatter can't compete with that.
So stop saying you've "already explained, at length, repeatedly".
>For instance, we all asked how many gate delays, power and area would the hypothetical
>gather/scatter cost to implement. How would it impact single threaded code (e.g.
>SPECint). I have yet to hear anything.
This is the first time I've read anyone explicitly ask about gate delays. But okay; there would be zero extra gate delays. That's because selecting four elements from a cache line instead of one, can be done in parallel. Also, calculating which of the elements are located within the same cache line, and computing their offset, can be done in parallel as well and isn't actually needed till the cache line has already been fetched. Of course fan-in/out increases at some points but (progressive) transistor sizing and/or input reordering can deal with that if necessary. Note that even if I'm wrong about any of this, you'll still also have to prove that the required extra gate delays are actually significant. A contemporary CPU can do 64-bit adds in one cycle and the gate delay for that is between 30 to 60 inverters (and that's without counting other delays to perform back-to-back operations). Since the CPU's clock frequency is increasingly less aggressive you can expect the gate delay budget to go up with every process node.
Next, I already detailed somewhere that emulating gather/scatter takes 24 uops which each pass over 128 bits of data around, and starves some of the other logic so it consumes idle power. Dedicated gather/scatter support would not occupy any of the ALU pipelines, and keeps the data being moved around to a bare minimum. So it's a big win in terms of power.
As for the area requirement, the element selection isn't all that different from the permute units in the ALUs. Other than that four 25-bit comparators and four 7-bit adders are needed (per LSU) but as indicated these can be relatively slow (and thus quite compact). Logic to keep multiple misses in flight is already in place. Of course the exact area requirement is hard to determine but feel free to fill me in if you want to prove it's too expensive. Note that Cell BE has 8 high-frequency 2-cycle-latency independent load/store units at 241 million transistors (looking at just the SPEs), while Sandy Bridge has four times the transistor budget, so asking for 8 load/store units capable of 4-element gather/scatter doesn't seem like a big deal to me.
And I've already pointed you to a paper which indicate that SPECint would be able to benefit from gather/scatter by about 20% thanks to more succesful parallelization of loops. SPECfp obviously benefits even more. So even for non-graphics workloads the area investment is clearly well worth it.
>Moreover, you make utterly unsubstantiated (and simply wrong) claims about the
>applicability of gather/scatter to ordinary code and claims about performance implications
>for SW rendering WITHOUT any substantiation. How do you know that single cycle
>scatter/gather is achievable? You don't even know the number of gate delays required.
You wrongfully assumed I didn't know the gate delays, and clearly you didn't know yourself since otherwise you wouldn't have asked.
And I did substantiate the applicability by noting that texel fetch is essentially a gather operation, which currently takes many uops to emulate. Lookup tables for transcendental functions also fit in L1 cache lines so those operations benefit substantially as well. And that's just scratching the surface.
Furthermore, the 20% benefit for SPECint merely requires the use of the 'restrict' keyword to statically determine dependencies (instead of dynamically as done by the paper). Even if static analysis yields lower benefit, it's highly doubtful that the investment isn't worth it. If that's not enough substantiation for you, feel free to take the opportunity to prove me wrong. Simply saying I don't provide enough positive proof does not count as negative proof.
[snip]
>Moreover, the data you provided was simply WRONG and BAD and DISCREDITED by the
>author of the simulator you used. Merely presenting spurious data isn't helpful to the conversation.
First of all, you haven't given me any indication at all what's wrong about it, nor how wrong it really is. The texture bandwidth of contemporary games may just as well be less than what's shown in that old ATTILA graph. So merely telling me the data is wrong doesn't prove your claims at all.
Secondly, I *measured* the number of uncompressed texture accesses for Crysis, and *conservatively* determined that it does not have a significant impact on bandwidth.
>>(*) P.S.: Just in case you still don't see it, the benefit >of unification is that
>>a homogenous CPU does not need to have the same compute >density as the IGP, to exceed
>>its effective performance. You basically get area for >free, which would have otherwise
>>remained largely idle (and you can trade it for power).
>
>How do you know it would have remained idle?
On my system with a GTX 460 and 3.2 GHz Nehalem, the Crysis CPU benchmark peaks at only 27% of CPU cycles. The average CPU usage is lower, and clearly with an IGP limiting the framerate the CPU usage would be lower still.
So the vast majority of CPU cycles are left unused. You can't ignore the unification benefit when comparing compute density.
>I agree it would be nice to have
>a unified architecture, but I think the reality is that processing in general is
>going to trend towards two distinct resources: latency optimized and throughput
>optimized, driven by the fundamental power and area efficiencies for separating the two.
There's two things separating latency optimized and throughput optimized hardware: architecture and design. Architecture isn't much of an argument though, due to the unification benefits. A homogenous architecture would have lower theoretical compute density than a GPU but like I said before that's fine since you already paid for the architectural latency optimizations to make it function as a CPU. For instance a bypass network takes extra wires and control logic but you need those for the CPU functionality anyway *and* it reduces the necessary register file size and reduces cache trashing. So at the architecture level the latency optimizations don't have to cost you anything thanks to unification.
So we're left mainly with design level differences. An area optimized ALU can be substantially smaller than an aggressively latency optimized one, exceeding any effective architectural benefit from the lower latency. That said, the MHz-race is long behind us, and things continue to converge on no less than three fronts! At 32 nm, the CPU's latencies are not aggressive at all. There's insane overclocking potential (even on air) and I believe all dynamic logic is gone. So Intel is optimizing for area and power as well. By the time gather/scatter is added there will be very little difference between CPU logic and IGP logic. Your lantency comparisons indicating an order of magnitude difference are invalid since you haven't taken the bypass network into account nor the instruction complexity and other stages.
Cheers,
Nicolas
Topic | Posted By | Date |
---|---|---|
Sandy Bridge CPU article online | David Kanter | 2010/09/26 08:35 PM |
Sandy Bridge CPU article online | Alex | 2010/09/27 04:22 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:06 AM |
Sandy Bridge CPU article online | someone | 2010/09/27 05:03 AM |
Sandy Bridge CPU article online | slacker | 2010/09/27 01:08 PM |
PowerPC is now Power | Paul A. Clayton | 2010/09/27 03:34 PM |
Sandy Bridge CPU article online | Dave | 2010/11/10 09:15 PM |
Sandy Bridge CPU article online | someone | 2010/09/27 05:23 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 05:39 PM |
Optimizing register clear | Paul A. Clayton | 2010/09/28 11:34 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 05:54 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:15 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 10:02 AM |
Sandy Bridge CPU article online | mpx | 2010/09/27 10:44 AM |
Sandy Bridge CPU article online | MS | 2010/09/27 01:37 PM |
Precisely | David Kanter | 2010/09/27 02:22 PM |
Sandy Bridge CPU article online | Richard Cownie | 2010/09/27 07:27 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 09:01 AM |
Sandy Bridge CPU article online | Richard Cownie | 2010/09/27 09:40 AM |
Sandy Bridge CPU article online | boots | 2010/09/27 10:19 AM |
Right, mid-2011, not 2010. Sorry (NT) | Richard Cownie | 2010/09/27 10:42 AM |
bulldozer single thread performance | Max | 2010/09/27 11:57 AM |
bulldozer single thread performance | Matt Waldhauer | 2011/03/02 10:32 AM |
Sandy Bridge CPU article online | Pun Zu | 2010/09/27 10:32 AM |
Sandy Bridge CPU article online | ? | 2010/09/27 10:44 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 12:11 PM |
My opinion is that anything that would take advantage of 256-bit AVX | redpriest | 2010/09/27 12:17 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/27 02:09 PM |
My opinion is that anything that would take advantage of 256-bit AVX | redpriest | 2010/09/27 03:06 PM |
My opinion is that anything that would take advantage of 256-bit AVX | David Kanter | 2010/09/27 04:23 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 02:57 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:35 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Matt Waldhauer | 2010/09/28 09:58 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/27 05:39 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:14 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Megol | 2010/09/28 01:17 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Michael S | 2010/09/28 04:47 AM |
PGI | Carlie Coats | 2010/09/28 09:23 AM |
gfortran... | Carlie Coats | 2010/09/29 08:33 AM |
My opinion is that anything that would take advantage of 256-bit AVX | mpx | 2010/09/28 11:58 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Michael S | 2010/09/28 12:36 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Foo_ | 2010/09/29 12:08 AM |
My opinion is that anything that would take advantage of 256-bit AVX | mpx | 2010/09/28 10:37 AM |
My opinion is that anything that would take advantage of 256-bit AVX | Aaron Spink | 2010/09/28 12:19 PM |
My opinion is that anything that would take advantage of 256-bit AVX | hobold | 2010/09/28 02:08 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Ian Ollmann | 2010/09/28 03:26 PM |
My opinion is that anything that would take advantage of 256-bit AVX | Anthony | 2010/09/28 09:31 PM |
Sandy Bridge CPU article online | Hans de Vries | 2010/09/27 01:19 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 02:19 PM |
Sandy Bridge CPU article online | -Sweeper_ | 2010/09/27 04:50 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 05:41 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/27 01:55 PM |
Sandy Bridge CPU article online | line98 | 2010/09/27 02:05 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 02:20 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/27 02:23 PM |
Sandy Bridge CPU article online | line98 | 2010/09/27 02:42 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 08:33 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 03:04 PM |
Sandy Bridge CPU article online | Jack | 2010/09/27 03:40 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 10:47 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/27 10:54 PM |
Sandy Bridge CPU article online | Royi | 2010/09/27 10:59 PM |
Sandy Bridge CPU article online | JS | 2010/09/28 12:18 AM |
Sandy Bridge CPU article online | Royi | 2010/09/28 12:31 AM |
Sandy Bridge CPU article online | Jack | 2010/09/28 05:34 AM |
Sandy Bridge CPU article online | Royi | 2010/09/28 07:22 AM |
Sandy Bridge CPU article online | Foo_ | 2010/09/28 11:53 AM |
Sandy Bridge CPU article online | Paul | 2010/09/28 12:17 PM |
Sandy Bridge CPU article online | mpx | 2010/09/28 12:22 PM |
Sandy Bridge CPU article online | anonymous | 2010/09/28 01:06 PM |
Sandy Bridge CPU article online | IntelUser2000 | 2010/09/29 12:49 AM |
Sandy Bridge CPU article online | Jack | 2010/09/28 04:08 PM |
Sandy Bridge CPU article online | mpx | 2010/09/29 12:50 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/29 11:01 AM |
Sandy Bridge CPU article online | Royi | 2010/09/29 11:48 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 01:15 PM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/29 01:27 PM |
Sandy Bridge CPU article online | ? | 2010/09/29 10:18 PM |
Sandy Bridge CPU article online | savantu | 2010/09/29 11:28 PM |
Sandy Bridge CPU article online | ? | 2010/09/30 02:43 AM |
Sandy Bridge CPU article online | gallier2 | 2010/09/30 03:18 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 07:38 AM |
Sandy Bridge CPU article online | David Hess | 2010/09/30 09:28 AM |
moderation (again) | hobold | 2010/10/01 04:08 AM |
Sandy Bridge CPU article online | Megol | 2010/09/30 01:13 AM |
Sandy Bridge CPU article online | ? | 2010/09/30 02:47 AM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 07:54 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 09:18 AM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 11:04 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 11:38 AM |
Sandy Bridge CPU article online | Michael S | 2010/09/30 12:02 PM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 07:09 PM |
Sandy Bridge CPU article online | mpx | 2010/09/30 11:40 AM |
Sandy Bridge CPU article online | Linus Torvalds | 2010/09/30 12:00 PM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 07:44 PM |
Sandy Bridge CPU article online | David Hess | 2010/09/30 09:36 AM |
Sandy Bridge CPU article online | someone | 2010/09/30 10:23 AM |
Sandy Bridge CPU article online | mpx | 2010/09/30 12:50 PM |
wii lesson | Michael S | 2010/09/30 01:12 PM |
wii lesson | Dan Downs | 2010/09/30 02:33 PM |
wii lesson | Kevin G | 2010/09/30 11:27 PM |
wii lesson | Rohit | 2010/10/01 06:53 AM |
wii lesson | Kevin G | 2010/10/02 02:30 AM |
wii lesson | mpx | 2010/10/01 08:02 AM |
wii lesson | IntelUser2000 | 2010/10/01 08:31 AM |
GPUs and games | David Kanter | 2010/09/30 07:17 PM |
GPUs and games | hobold | 2010/10/01 04:27 AM |
GPUs and games | anonymous | 2010/10/01 05:35 AM |
GPUs and games | Gabriele Svelto | 2010/10/01 08:07 AM |
GPUs and games | Linus Torvalds | 2010/10/01 09:41 AM |
GPUs and games | Anon | 2010/10/01 10:23 AM |
Can Intel do *this* ??? | Mark Roulo | 2010/10/03 02:17 PM |
Can Intel do *this* ??? | Anon | 2010/10/03 02:29 PM |
Can Intel do *this* ??? | Mark Roulo | 2010/10/03 02:55 PM |
Can Intel do *this* ??? | Anon | 2010/10/03 04:45 PM |
Can Intel do *this* ??? | Ian Ameline | 2010/10/03 09:35 PM |
Graphics, IGPs, and Cache | Joe | 2010/10/10 08:51 AM |
Graphics, IGPs, and Cache | Anon | 2010/10/10 09:18 PM |
Graphics, IGPs, and Cache | Rohit | 2010/10/11 05:14 AM |
Graphics, IGPs, and Cache | hobold | 2010/10/11 05:43 AM |
Maybe the IGPU doesn't load into the L3 | Mark Roulo | 2010/10/11 07:05 AM |
Graphics, IGPs, and Cache | David Kanter | 2010/10/11 08:01 AM |
Can Intel do *this* ??? | Gabriele Svelto | 2010/10/03 11:31 PM |
Kanter's Law. | Ian Ameline | 2010/10/01 01:05 PM |
Kanter's Law. | David Kanter | 2010/10/01 01:18 PM |
Kanter's Law. | Ian Ameline | 2010/10/01 01:33 PM |
Kanter's Law. | Kevin G | 2010/10/01 03:19 PM |
Kanter's Law. | IntelUser2000 | 2010/10/01 09:36 PM |
Kanter's Law. | Kevin G | 2010/10/02 02:15 AM |
Kanter's Law. | IntelUser2000 | 2010/10/02 01:35 PM |
Wii vs pc's | Rohit | 2010/10/01 06:34 PM |
Wii vs pc's | Gabriele Svelto | 2010/10/01 10:54 PM |
GPUs and games | mpx | 2010/10/02 10:30 AM |
GPUs and games | Foo_ | 2010/10/02 03:03 PM |
GPUs and games | mpx | 2010/10/03 10:29 AM |
GPUs and games | Foo_ | 2010/10/03 12:52 PM |
GPUs and games | mpx | 2010/10/03 02:29 PM |
GPUs and games | Anon | 2010/10/03 02:49 PM |
GPUs and games | mpx | 2010/10/04 10:42 AM |
GPUs and games | MS | 2010/10/04 01:51 PM |
GPUs and games | Anon | 2010/10/04 07:29 PM |
persistence of vision | hobold | 2010/10/04 10:47 PM |
GPUs and games | mpx | 2010/10/04 11:51 PM |
GPUs and games | MS | 2010/10/05 05:49 AM |
GPUs and games | Jack | 2010/10/05 10:17 AM |
GPUs and games | MS | 2010/10/05 04:19 PM |
GPUs and games | Jack | 2010/10/05 10:11 AM |
GPUs and games | mpx | 2010/10/05 11:51 AM |
GPUs and games | David Kanter | 2010/10/06 08:04 AM |
GPUs and games | jack | 2010/10/06 08:34 PM |
GPUs and games | Linus Torvalds | 2010/10/05 06:29 AM |
GPUs and games | Foo_ | 2010/10/04 03:49 AM |
GPUs and games | Jeremiah | 2010/10/08 09:58 AM |
GPUs and games | MS | 2010/10/08 12:37 PM |
GPUs and games | Salvatore De Dominicis | 2010/10/04 12:41 AM |
GPUs and games | Kevin G | 2010/10/05 01:13 PM |
GPUs and games | mpx | 2010/10/03 10:36 AM |
GPUs and games | David Kanter | 2010/10/04 06:08 AM |
GPUs and games | Kevin G | 2010/10/04 09:38 AM |
Sandy Bridge CPU article online | NEON cortex | 2010/11/17 08:19 PM |
Sandy Bridge CPU article online | Ian Ameline | 2010/09/30 11:06 AM |
Sandy Bridge CPU article online | rwessel | 2010/09/30 01:29 PM |
Sandy Bridge CPU article online | Michael S | 2010/09/30 02:06 PM |
Sandy Bridge CPU article online | rwessel | 2010/09/30 05:55 PM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 02:53 AM |
Sandy Bridge CPU article online | rwessel | 2010/10/01 07:30 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 08:31 AM |
Sandy Bridge CPU article online | rwessel | 2010/10/01 09:56 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:28 PM |
Sandy Bridge CPU article online | Ricardo B | 2010/10/02 04:38 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/02 05:59 PM |
which bus more wasteful | Michael S | 2010/10/02 09:38 AM |
which bus more wasteful | rwessel | 2010/10/02 06:15 PM |
Sandy Bridge CPU article online | Ricardo B | 2010/10/01 09:08 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:31 PM |
Sandy Bridge CPU article online | Andi Kleen | 2010/10/01 10:55 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:32 PM |
Sandy Bridge CPU article online | kdg | 2010/10/01 10:26 AM |
Sandy Bridge CPU article online | Anon | 2010/10/01 10:33 AM |
Analog display out? | David Kanter | 2010/10/01 12:05 PM |
Analog display out? | mpx | 2010/10/02 10:46 AM |
Analog display out? | Anon | 2010/10/03 02:26 PM |
Digital is expensive! | David Kanter | 2010/10/03 05:36 PM |
Digital is expensive! | Anon | 2010/10/03 07:07 PM |
Digital is expensive! | David Kanter | 2010/10/03 09:02 PM |
Digital is expensive! | Steve Underwood | 2010/10/04 02:52 AM |
Digital is expensive! | David Kanter | 2010/10/04 06:03 AM |
Digital is expensive! | anonymous | 2010/10/04 06:11 AM |
Digital is not very expensive! | Steve Underwood | 2010/10/04 05:08 PM |
Digital is not very expensive! | Anon | 2010/10/04 07:33 PM |
Digital is not very expensive! | Steve Underwood | 2010/10/04 10:03 PM |
Digital is not very expensive! | mpx | 2010/10/05 12:10 PM |
Digital is not very expensive! | Gabriele Svelto | 2010/10/04 11:24 PM |
Digital is expensive! | jal142 | 2010/10/04 10:46 AM |
Digital is expensive! | mpx | 2010/10/04 12:04 AM |
Digital is expensive! | Gabriele Svelto | 2010/10/04 02:28 AM |
Digital is expensive! | Mark Christiansen | 2010/10/04 02:12 PM |
Analog display out? | slacker | 2010/10/03 05:44 PM |
Analog display out? | Anon | 2010/10/03 07:05 PM |
Analog display out? | Steve Underwood | 2010/10/04 02:48 AM |
Sandy Bridge CPU article online | David Hess | 2010/10/01 07:37 PM |
Sandy Bridge CPU article online | slacker | 2010/10/02 01:53 PM |
Sandy Bridge CPU article online | David Hess | 2010/10/02 05:49 PM |
memory bandwith | Max | 2010/09/30 11:19 AM |
memory bandwith | Anon | 2010/10/01 10:28 AM |
memory bandwith | Jack | 2010/10/01 06:45 PM |
memory bandwith | Anon | 2010/10/03 02:19 PM |
Sandy Bridge CPU article online | PiedPiper | 2010/09/30 06:05 PM |
Sandy Bridge CPU article online | Matt Sayler | 2010/09/29 03:38 PM |
Sandy Bridge CPU article online | Jack | 2010/09/29 08:39 PM |
Sandy Bridge CPU article online | mpx | 2010/09/29 11:24 PM |
Sandy Bridge CPU article online | passer | 2010/09/30 02:15 AM |
Sandy Bridge CPU article online | mpx | 2010/09/30 02:47 AM |
Sandy Bridge CPU article online | passer | 2010/09/30 03:25 AM |
SB and web browsing | Rohit | 2010/09/30 05:47 AM |
SB and web browsing | David Hess | 2010/09/30 06:10 AM |
SB and web browsing | MS | 2010/09/30 09:21 AM |
SB and web browsing | passer | 2010/09/30 09:26 AM |
SB and web browsing | MS | 2010/10/02 05:41 PM |
SB and web browsing | Rohit | 2010/10/01 07:02 AM |
Sandy Bridge CPU article online | David Kanter | 2010/09/30 07:35 AM |
Sandy Bridge CPU article online | Jack | 2010/09/30 09:40 PM |
processor evolution | hobold | 2010/09/29 01:16 PM |
processor evolution | Foo_ | 2010/09/30 05:10 AM |
processor evolution | Jack | 2010/09/30 06:07 PM |
3D gaming as GPGPU app | hobold | 2010/10/01 03:59 AM |
3D gaming as GPGPU app | Jack | 2010/10/01 06:39 PM |
processor evolution | hobold | 2010/10/01 03:35 AM |
processor evolution | David Kanter | 2010/10/01 09:02 AM |
processor evolution | Anon | 2010/10/01 10:46 AM |
Display | David Kanter | 2010/10/01 12:26 PM |
Display | Rohit | 2010/10/02 01:56 AM |
Display | Linus Torvalds | 2010/10/02 06:40 AM |
Display | rwessel | 2010/10/02 07:58 AM |
Display | sJ | 2010/10/02 09:28 PM |
Display | rwessel | 2010/10/03 07:38 AM |
Display | Anon | 2010/10/03 02:06 PM |
Display tech and compute are different | David Kanter | 2010/10/03 05:33 PM |
Display tech and compute are different | Anon | 2010/10/03 07:16 PM |
Display tech and compute are different | David Kanter | 2010/10/03 09:00 PM |
Display tech and compute are different | hobold | 2010/10/04 12:40 AM |
Display | ? | 2010/10/03 02:02 AM |
Display | Linus Torvalds | 2010/10/03 09:18 AM |
Display | Richard Cownie | 2010/10/03 10:12 AM |
Display | Linus Torvalds | 2010/10/03 11:16 AM |
Display | slacker | 2010/10/03 06:35 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/04 06:06 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/04 10:44 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/04 01:59 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/04 02:13 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/04 07:58 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/05 12:39 AM |
current V12 engines with >6.0 displacement | MS | 2010/10/05 05:57 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/05 12:20 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/05 08:26 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 04:39 AM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 12:22 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/06 02:07 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 02:56 PM |
current V12 engines with >6.0 displacement | rwessel | 2010/10/06 02:30 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 02:53 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/07 12:32 PM |
current V12 engines with >6.0 displacement | rwessel | 2010/10/07 06:54 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 08:02 PM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | slacker | 2010/10/06 06:20 PM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | Ricardo B | 2010/10/07 12:32 AM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | slacker | 2010/10/07 07:15 AM |
Top Gear is awful, and Jeremy Clarkson cannot drive. | Ricardo B | 2010/10/07 09:51 AM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 04:03 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 05:26 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 10:15 PM |
current V12 engines with >6.0 displacement | Howard Chu | 2010/10/07 01:16 PM |
current V12 engines with >6.0 displacement | Anon | 2010/10/05 09:31 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 04:55 AM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/06 05:15 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/06 05:34 AM |
I wonder is there any tech area that this forum doesn't have an opinion on (NT) | Rob Thorpe | 2010/10/06 09:11 AM |
Cunieform tablets | David Kanter | 2010/10/06 11:57 AM |
Cunieform tablets | Linus Torvalds | 2010/10/06 12:06 PM |
Ouch...maybe I should hire a new editor (NT) | David Kanter | 2010/10/06 03:38 PM |
Cunieform tablets | rwessel | 2010/10/06 02:41 PM |
Cunieform tablets | seni | 2010/10/07 09:56 AM |
Cunieform tablets | Howard Chu | 2010/10/07 12:44 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/06 05:10 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/06 09:44 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 06:55 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 07:51 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 06:38 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 07:33 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/07 08:04 PM |
Practical vehicles for commuting | Rob Thorpe | 2010/10/08 04:50 AM |
Practical vehicles for commuting | Gabriele Svelto | 2010/10/08 05:05 AM |
Practical vehicles for commuting | Rob Thorpe | 2010/10/08 05:21 AM |
Practical vehicles for commuting | j | 2010/10/08 01:20 PM |
Practical vehicles for commuting | Rob Thorpe | 2010/12/09 06:00 AM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/08 09:14 AM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/07 12:23 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/07 03:08 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 04:41 PM |
current V12 engines with >6.0 displacement | slacker | 2010/10/07 07:05 PM |
current V12 engines with >6.0 displacement | anonymous | 2010/10/07 07:52 PM |
current V12 engines with >6.0 displacement | Anonymous | 2010/10/08 06:52 PM |
current V12 engines with >6.0 displacement | anon | 2010/10/06 10:28 PM |
current V12 engines with >6.0 displacement | Aaron Spink | 2010/10/06 11:37 PM |
current V12 engines with >6.0 displacement | Ricardo B | 2010/10/07 12:37 AM |
current V12 engines with >6.0 displacement | slacker | 2010/10/05 01:02 AM |
Display | Linus Torvalds | 2010/10/04 09:39 AM |
Display | Gabriele Svelto | 2010/10/04 11:34 PM |
Display | Richard Cownie | 2010/10/04 05:22 AM |
Display | anon | 2010/10/04 08:22 PM |
Display | Richard Cownie | 2010/10/05 05:42 AM |
Display | mpx | 2010/10/03 10:55 AM |
Display | rcf | 2010/10/03 12:12 PM |
Display | mpx | 2010/10/03 01:36 PM |
Display | rcf | 2010/10/03 04:36 PM |
Display | Ricardo B | 2010/10/04 01:50 PM |
Display | gallier2 | 2010/10/05 02:44 AM |
Display | David Hess | 2010/10/05 04:21 AM |
Display | gallier2 | 2010/10/05 07:21 AM |
Display | David Hess | 2010/10/03 10:21 PM |
Display | rcf | 2010/10/04 07:06 AM |
Display | David Kanter | 2010/10/03 12:54 PM |
Alternative integration | Paul A. Clayton | 2010/10/06 07:51 AM |
Display | slacker | 2010/10/03 06:26 PM |
Display & marketing & analogies | ? | 2010/10/04 01:33 AM |
Display & marketing & analogies | kdg | 2010/10/04 05:00 AM |
Display | Kevin G | 2010/10/02 08:49 AM |
Display | Anon | 2010/10/03 02:43 PM |
Sandy Bridge CPU article online | David Kanter | 2010/09/29 02:17 PM |
Sandy Bridge CPU article online | Jack | 2010/09/28 05:27 AM |
Sandy Bridge CPU article online | IntelUser2000 | 2010/09/28 02:07 AM |
Sandy Bridge CPU article online | mpx | 2010/09/28 11:34 AM |
Sandy Bridge CPU article online | Aaron Spink | 2010/09/28 12:28 PM |
Sandy Bridge CPU article online | JoshW | 2010/09/28 01:13 PM |
Sandy Bridge CPU article online | mpx | 2010/09/28 01:54 PM |
Sandy Bridge CPU article online | Foo_ | 2010/09/29 12:19 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 02:06 AM |
Sandy Bridge CPU article online | JS | 2010/09/29 02:42 AM |
Sandy Bridge CPU article online | mpx | 2010/09/29 03:03 AM |
Sandy Bridge CPU article online | Foo_ | 2010/09/29 04:55 AM |
Sandy Bridge CPU article online | ajensen | 2010/09/27 11:19 PM |
Sandy Bridge CPU article online | Ian Ollmann | 2010/09/28 03:52 PM |
Sandy Bridge CPU article online | a reader | 2010/09/28 04:05 PM |
Sandy Bridge CPU article online | ajensen | 2010/09/28 10:35 PM |
Updated: Sandy Bridge CPU article | David Kanter | 2010/10/01 04:11 AM |
Updated: Sandy Bridge CPU article | anon | 2011/01/07 08:55 PM |
Updated: Sandy Bridge CPU article | Eric Bron | 2011/01/08 02:29 AM |
Updated: Sandy Bridge CPU article | anon | 2011/01/11 10:24 PM |
Updated: Sandy Bridge CPU article | anon | 2011/01/15 10:21 AM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anon | 2011/01/16 10:22 PM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anonymous | 2011/01/17 01:04 AM |
David Kanter can you shed some light? Re Updated: Sandy Bridge CPU article | anon | 2011/01/17 06:12 AM |
I can try.... | David Kanter | 2011/01/18 02:54 PM |
I can try.... | anon | 2011/01/18 07:07 PM |
I can try.... | David Kanter | 2011/01/18 10:24 PM |
I can try.... | anon | 2011/01/19 06:51 AM |
Wider fetch than execute makes sense | Paul A. Clayton | 2011/01/19 07:53 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/04 06:29 AM |
Sandy Bridge CPU article online | Seni | 2011/01/04 08:07 PM |
Sandy Bridge CPU article online | hobold | 2011/01/04 10:26 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 01:01 AM |
software assist exceptions | hobold | 2011/01/05 03:36 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 12:58 AM |
Sandy Bridge CPU article online | anon | 2011/01/05 03:51 AM |
Sandy Bridge CPU article online | Seni | 2011/01/05 07:53 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 08:03 AM |
Sandy Bridge CPU article online | anon | 2011/01/05 03:14 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 03:50 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/05 04:00 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 06:26 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/05 06:50 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 07:39 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 02:50 PM |
permuting vector elements | hobold | 2011/01/05 04:03 PM |
permuting vector elements | Nicolas Capens | 2011/01/05 05:01 PM |
permuting vector elements | Nicolas Capens | 2011/01/06 07:27 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/11 10:33 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/11 12:51 PM |
Sandy Bridge CPU article online | hobold | 2011/01/11 01:11 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/11 05:07 PM |
Sandy Bridge CPU article online | Michael S | 2011/01/12 02:25 AM |
Sandy Bridge CPU article online | hobold | 2011/01/12 04:03 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/12 10:27 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/13 01:38 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/13 02:32 AM |
Sandy Bridge CPU article online | hobold | 2011/01/13 12:53 PM |
What happened to VPERMIL2PS? | Michael S | 2011/01/13 02:46 AM |
What happened to VPERMIL2PS? | Eric Bron | 2011/01/13 05:46 AM |
Lower cost permute | Paul A. Clayton | 2011/01/13 11:11 AM |
Sandy Bridge CPU article online | anon | 2011/01/25 05:31 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/12 05:34 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/13 06:38 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/15 08:47 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/01/16 02:13 AM |
And just to make a further example | Gabriele Svelto | 2011/01/16 03:24 AM |
Sandy Bridge CPU article online | mpx | 2011/01/16 12:27 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/25 01:56 PM |
Sandy Bridge CPU article online | David Kanter | 2011/01/25 03:11 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/26 07:49 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/26 03:35 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/27 01:51 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/27 01:40 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/28 02:24 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/28 02:49 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/30 01:11 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/31 02:43 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/01 03:02 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/01 03:28 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/01 03:43 AM |
Sandy Bridge CPU article online | EduardoS | 2011/01/28 06:14 PM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/01 01:58 AM |
Sandy Bridge CPU article online | EduardoS | 2011/02/01 01:36 PM |
Sandy Bridge CPU article online | anon | 2011/02/01 03:56 PM |
Sandy Bridge CPU article online | EduardoS | 2011/02/01 08:17 PM |
Sandy Bridge CPU article online | anon | 2011/02/01 09:13 PM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/02 03:08 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/02/02 03:26 AM |
Sandy Bridge CPU article online | kalmaegi | 2011/02/01 08:29 AM |
SW Rasterization | David Kanter | 2011/01/27 04:18 PM |
Lower pin count memory | iz | 2011/01/27 08:19 PM |
Lower pin count memory | David Kanter | 2011/01/27 08:25 PM |
Lower pin count memory | iz | 2011/01/27 10:31 PM |
Lower pin count memory | David Kanter | 2011/01/27 10:52 PM |
Lower pin count memory | iz | 2011/01/27 11:28 PM |
Lower pin count memory | David Kanter | 2011/01/28 12:05 AM |
Lower pin count memory | iz | 2011/01/28 02:55 AM |
Lower pin count memory | David Hess | 2011/01/28 12:15 PM |
Lower pin count memory | David Kanter | 2011/01/28 12:57 PM |
Lower pin count memory | iz | 2011/01/28 04:20 PM |
Two years later | ForgotPants | 2013/10/26 10:33 AM |
Two years later | anon | 2013/10/26 10:36 AM |
Two years later | Exophase | 2013/10/26 11:56 AM |
Two years later | David Hess | 2013/10/26 04:05 PM |
Herz is totally the thing you DON*T care. | Jouni Osmala | 2013/10/27 12:48 AM |
Herz is totally the thing you DON*T care. | EduardoS | 2013/10/27 06:00 AM |
Herz is totally the thing you DON*T care. | Michael S | 2013/10/27 06:45 AM |
Two years later | someone | 2013/10/28 06:21 AM |
Lower pin count memory | Martin Høyer Kristiansen | 2011/01/28 12:41 AM |
Lower pin count memory | iz | 2011/01/28 02:07 AM |
Lower pin count memory | Darrell Coker | 2011/01/27 09:39 PM |
Lower pin count memory | iz | 2011/01/27 11:20 PM |
Lower pin count memory | Darrell Coker | 2011/01/28 05:07 PM |
Lower pin count memory | iz | 2011/01/28 10:57 PM |
Lower pin count memory | Darrell Coker | 2011/01/29 01:21 AM |
Lower pin count memory | iz | 2011/01/31 09:28 PM |
SW Rasterization | Nicolas Capens | 2011/02/02 07:48 AM |
SW Rasterization | Eric Bron | 2011/02/02 08:37 AM |
SW Rasterization | Nicolas Capens | 2011/02/02 03:35 PM |
SW Rasterization | Eric Bron | 2011/02/02 04:11 PM |
SW Rasterization | Eric Bron | 2011/02/03 01:13 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 06:57 AM |
SW Rasterization | Eric Bron | 2011/02/04 07:50 AM |
erratum | Eric Bron | 2011/02/04 07:58 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 04:25 PM |
SW Rasterization | David Kanter | 2011/02/04 04:33 PM |
SW Rasterization | anon | 2011/02/04 05:04 PM |
SW Rasterization | Nicolas Capens | 2011/02/05 02:39 PM |
SW Rasterization | David Kanter | 2011/02/05 04:07 PM |
SW Rasterization | Nicolas Capens | 2011/02/05 10:39 PM |
SW Rasterization | Eric Bron | 2011/02/04 09:55 AM |
Comments pt 1 | David Kanter | 2011/02/02 12:08 PM |
Comments pt 1 | Eric Bron | 2011/02/02 02:16 PM |
Comments pt 1 | Gabriele Svelto | 2011/02/03 12:37 AM |
Comments pt 1 | Eric Bron | 2011/02/03 01:36 AM |
Comments pt 1 | Nicolas Capens | 2011/02/03 10:08 PM |
Comments pt 1 | Nicolas Capens | 2011/02/03 09:26 PM |
Comments pt 1 | Eric Bron | 2011/02/04 02:33 AM |
Comments pt 1 | Nicolas Capens | 2011/02/04 04:24 AM |
example code | Eric Bron | 2011/02/04 03:51 AM |
example code | Nicolas Capens | 2011/02/04 07:24 AM |
example code | Eric Bron | 2011/02/04 07:36 AM |
example code | Nicolas Capens | 2011/02/05 10:43 PM |
Comments pt 1 | Rohit | 2011/02/04 11:43 AM |
Comments pt 1 | Nicolas Capens | 2011/02/04 04:05 PM |
Comments pt 1 | David Kanter | 2011/02/04 04:36 PM |
Comments pt 1 | Nicolas Capens | 2011/02/05 01:45 PM |
Comments pt 1 | Eric Bron | 2011/02/05 03:13 PM |
Comments pt 1 | Nicolas Capens | 2011/02/05 10:52 PM |
Comments pt 1 | Eric Bron | 2011/02/06 12:31 AM |
Comments pt 1 | Nicolas Capens | 2011/02/06 03:06 PM |
Comments pt 1 | Eric Bron | 2011/02/07 02:12 AM |
The need for gather/scatter support | Nicolas Capens | 2011/02/10 09:07 AM |
The need for gather/scatter support | Eric Bron | 2011/02/11 02:11 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/13 02:39 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 06:46 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 06:48 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 08:32 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 09:07 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 08:00 AM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 06:49 AM |
Gather/scatter performance data | Eric Bron | 2011/02/15 01:23 AM |
Gather/scatter performance data | Eric Bron | 2011/02/13 04:06 PM |
Gather/scatter performance data | Nicolas Capens | 2011/02/14 06:52 AM |
Gather/scatter performance data | Eric Bron | 2011/02/14 08:43 AM |
SW Rasterization - a long way off | Rohit | 2011/02/02 12:17 PM |
SW Rasterization - a long way off | Nicolas Capens | 2011/02/04 02:59 AM |
CPU only rendering - a long way off | Rohit | 2011/02/04 10:52 AM |
CPU only rendering - a long way off | Nicolas Capens | 2011/02/04 06:15 PM |
CPU only rendering - a long way off | Rohit | 2011/02/05 01:00 AM |
CPU only rendering - a long way off | Nicolas Capens | 2011/02/05 08:45 PM |
CPU only rendering - a long way off | David Kanter | 2011/02/06 08:51 PM |
CPU only rendering - a long way off | Gian-Carlo Pascutto | 2011/02/06 11:22 PM |
Encryption | David Kanter | 2011/02/07 12:18 AM |
Encryption | Nicolas Capens | 2011/02/07 06:51 AM |
Encryption | David Kanter | 2011/02/07 10:50 AM |
Encryption | Nicolas Capens | 2011/02/08 09:26 AM |
CPUs are latency optimized | David Kanter | 2011/02/08 10:38 AM |
efficient compiler on an efficient GPU real today. | sJ | 2011/02/08 10:29 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/09 08:49 PM |
CPUs are latency optimized | Eric Bron | 2011/02/09 11:49 PM |
CPUs are latency optimized | Antti-Ville Tuunainen | 2011/02/10 05:16 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/10 06:04 AM |
CPUs are latency optimized | Eric Bron | 2011/02/10 06:48 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/10 12:31 PM |
CPUs are latency optimized | Eric Bron | 2011/02/11 01:43 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/11 06:31 AM |
CPUs are latency optimized | EduardoS | 2011/02/10 04:29 PM |
CPUs are latency optimized | Anon | 2011/02/10 05:40 PM |
CPUs are latency optimized | David Kanter | 2011/02/10 07:33 PM |
CPUs are latency optimized | EduardoS | 2011/02/11 01:18 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/11 04:56 AM |
CPUs are latency optimized | Rohit | 2011/02/11 06:33 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/14 01:19 AM |
CPUs are latency optimized | Eric Bron | 2011/02/14 02:23 AM |
CPUs are latency optimized | EduardoS | 2011/02/14 12:11 PM |
CPUs are latency optimized | David Kanter | 2011/02/11 01:45 PM |
CPUs are latency optimized | Nicolas Capens | 2011/02/15 04:22 AM |
CPUs are latency optimized | David Kanter | 2011/02/15 11:47 AM |
CPUs are latency optimized | Nicolas Capens | 2011/02/15 06:10 PM |
Have fun | David Kanter | 2011/02/15 09:04 PM |
Have fun | Nicolas Capens | 2011/02/17 02:59 AM |
Have fun | Brett | 2011/02/17 11:56 AM |
Have fun | Nicolas Capens | 2011/02/19 03:53 PM |
Have fun | Brett | 2011/02/20 05:08 PM |
Have fun | Brett | 2011/02/20 06:13 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/02/23 04:37 PM |
On-die storage to fight Amdahl | Brett | 2011/02/23 08:59 PM |
On-die storage to fight Amdahl | Brett | 2011/02/23 09:08 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/02/24 06:42 PM |
On-die storage to fight Amdahl | Rohit | 2011/02/25 10:02 PM |
On-die storage to fight Amdahl | Nicolas Capens | 2011/03/09 05:53 PM |
On-die storage to fight Amdahl | Rohit | 2011/03/10 07:02 AM |
NVIDIA using tile based rendering? | Nathan Monson | 2011/03/11 06:58 PM |
NVIDIA using tile based rendering? | Rohit | 2011/03/12 03:29 AM |
NVIDIA using tile based rendering? | Nathan Monson | 2011/03/12 10:05 AM |
NVIDIA using tile based rendering? | Rohit | 2011/03/12 10:16 AM |
On-die storage to fight Amdahl | Brett | 2011/02/26 01:10 AM |
On-die storage to fight Amdahl | Nathan Monson | 2011/02/26 12:51 PM |
On-die storage to fight Amdahl | Brett | 2011/02/26 03:40 PM |
Convergence is inevitable | Nicolas Capens | 2011/03/09 07:22 PM |
Convergence is inevitable | Brett | 2011/03/09 09:59 PM |
Convergence is inevitable | Antti-Ville Tuunainen | 2011/03/10 02:34 PM |
Convergence is inevitable | Brett | 2011/03/10 08:39 PM |
Procedural texturing? | David Kanter | 2011/03/11 12:32 AM |
Procedural texturing? | hobold | 2011/03/11 02:59 AM |
Procedural texturing? | Dan Downs | 2011/03/11 08:28 AM |
Procedural texturing? | Mark Roulo | 2011/03/11 01:58 PM |
Procedural texturing? | Anon | 2011/03/11 05:11 PM |
Procedural texturing? | Nathan Monson | 2011/03/11 06:30 PM |
Procedural texturing? | Brett | 2011/03/15 06:45 AM |
Procedural texturing? | Seni | 2011/03/15 09:13 AM |
Procedural texturing? | Brett | 2011/03/15 10:45 AM |
Procedural texturing? | Seni | 2011/03/15 01:09 PM |
Procedural texturing? | Brett | 2011/03/11 09:02 PM |
Procedural texturing? | Brett | 2011/03/11 08:34 PM |
Procedural texturing? | Eric Bron | 2011/03/12 02:37 AM |
Convergence is inevitable | Jouni Osmala | 2011/03/09 10:28 PM |
Convergence is inevitable | Brett | 2011/04/05 04:08 PM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 04:23 AM |
Convergence is inevitable | none | 2011/04/07 06:03 AM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 09:34 AM |
Convergence is inevitable | anon | 2011/04/07 01:15 PM |
Convergence is inevitable | none | 2011/04/08 12:57 AM |
Convergence is inevitable | Brett | 2011/04/07 07:04 PM |
Convergence is inevitable | none | 2011/04/08 01:14 AM |
Gather implementation | David Kanter | 2011/04/08 11:01 AM |
RAM Latency | David Hess | 2011/04/07 07:22 AM |
RAM Latency | Brett | 2011/04/07 06:20 PM |
RAM Latency | Nicolas Capens | 2011/04/07 09:18 PM |
RAM Latency | Brett | 2011/04/08 04:33 AM |
RAM Latency | Nicolas Capens | 2011/04/10 01:23 PM |
RAM Latency | Rohit | 2011/04/08 05:57 AM |
RAM Latency | Nicolas Capens | 2011/04/10 12:23 PM |
RAM Latency | David Kanter | 2011/04/10 01:27 PM |
RAM Latency | Rohit | 2011/04/11 05:17 AM |
Convergence is inevitable | Eric Bron | 2011/04/07 08:46 AM |
Convergence is inevitable | Nicolas Capens | 2011/04/07 08:50 PM |
Convergence is inevitable | Eric Bron | 2011/04/07 11:39 PM |
Flaws in PowerVR | Rohit | 2011/02/25 10:21 PM |
Flaws in PowerVR | Brett | 2011/02/25 11:37 PM |
Flaws in PowerVR | Paul | 2011/02/26 04:17 AM |
Have fun | David Kanter | 2011/02/18 11:52 AM |
Have fun | Michael S | 2011/02/19 11:12 AM |
Have fun | David Kanter | 2011/02/19 02:26 PM |
Have fun | Michael S | 2011/02/19 03:43 PM |
Have fun | anon | 2011/02/19 04:02 PM |
Have fun | Michael S | 2011/02/19 04:56 PM |
Have fun | anon | 2011/02/20 02:50 PM |
Have fun | EduardoS | 2011/02/20 01:44 PM |
Linear vs non-linear | EduardoS | 2011/02/20 01:55 PM |
Have fun | Michael S | 2011/02/20 03:19 PM |
Have fun | EduardoS | 2011/02/20 04:51 PM |
Have fun | Nicolas Capens | 2011/02/21 10:12 AM |
Have fun | Michael S | 2011/02/21 11:38 AM |
Have fun | Eric Bron | 2011/02/21 01:10 PM |
Have fun | Eric Bron | 2011/02/21 01:39 PM |
Have fun | Michael S | 2011/02/21 05:13 PM |
Have fun | Eric Bron | 2011/02/21 11:43 PM |
Have fun | Michael S | 2011/02/22 12:47 AM |
Have fun | Eric Bron | 2011/02/22 01:10 AM |
Have fun | Michael S | 2011/02/22 10:37 AM |
Have fun | anon | 2011/02/22 12:38 PM |
Have fun | EduardoS | 2011/02/22 02:49 PM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/23 05:37 PM |
Gather/scatter efficiency | anonymous | 2011/02/23 05:51 PM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/24 05:57 PM |
Gather/scatter efficiency | anonymous | 2011/02/24 06:16 PM |
Gather/scatter efficiency | Michael S | 2011/02/25 06:45 AM |
Gather implementation | David Kanter | 2011/02/25 04:34 PM |
Gather implementation | Michael S | 2011/02/26 09:40 AM |
Gather implementation | anon | 2011/02/26 10:52 AM |
Gather implementation | Michael S | 2011/02/26 11:16 AM |
Gather implementation | anon | 2011/02/26 10:22 PM |
Gather implementation | Michael S | 2011/02/27 06:23 AM |
Gather/scatter efficiency | Nicolas Capens | 2011/02/28 02:14 PM |
Consider yourself ignored | David Kanter | 2011/02/22 12:05 AM |
one more anti-FMA flame. By me. | Michael S | 2011/02/16 06:40 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/16 07:30 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/16 08:15 AM |
one more anti-FMA flame. By me. | Nicolas Capens | 2011/02/17 05:27 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/17 06:42 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/17 04:46 PM |
Tarantula paper | Paul A. Clayton | 2011/02/17 11:38 PM |
Tarantula paper | Nicolas Capens | 2011/02/19 04:19 PM |
anti-FMA != anti-throughput or anti-SG | Eric Bron | 2011/02/18 12:48 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/20 02:46 PM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/20 04:00 PM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 03:05 AM |
Software pipelining on x86 | David Kanter | 2011/02/23 04:04 AM |
Software pipelining on x86 | JS | 2011/02/23 04:25 AM |
Software pipelining on x86 | Salvatore De Dominicis | 2011/02/23 07:37 AM |
Software pipelining on x86 | Jouni Osmala | 2011/02/23 08:10 AM |
Software pipelining on x86 | LeeMiller | 2011/02/23 09:07 PM |
Software pipelining on x86 | Nicolas Capens | 2011/02/24 02:17 PM |
Software pipelining on x86 | anonymous | 2011/02/24 06:04 PM |
Software pipelining on x86 | Nicolas Capens | 2011/02/28 08:27 AM |
Software pipelining on x86 | Antti-Ville Tuunainen | 2011/03/02 03:31 AM |
Software pipelining on x86 | Megol | 2011/03/02 11:55 AM |
Software pipelining on x86 | Geert Bosch | 2011/03/03 06:58 AM |
FMA benefits and latency predictions | David Kanter | 2011/02/25 04:14 PM |
FMA benefits and latency predictions | Antti-Ville Tuunainen | 2011/02/26 09:43 AM |
FMA benefits and latency predictions | Matt Waldhauer | 2011/02/27 05:42 AM |
FMA benefits and latency predictions | Nicolas Capens | 2011/03/09 05:11 PM |
FMA benefits and latency predictions | Rohit | 2011/03/10 07:11 AM |
FMA benefits and latency predictions | Eric Bron | 2011/03/10 08:30 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/23 04:19 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 06:50 AM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/23 09:37 AM |
FMA and beyond | Nicolas Capens | 2011/02/24 03:47 PM |
detour on terminology | hobold | 2011/02/24 06:08 PM |
detour on terminology | Nicolas Capens | 2011/02/28 01:24 PM |
detour on terminology | Eric Bron | 2011/03/01 01:38 AM |
detour on terminology | Michael S | 2011/03/01 04:03 AM |
detour on terminology | Eric Bron | 2011/03/01 04:39 AM |
detour on terminology | Michael S | 2011/03/01 07:33 AM |
detour on terminology | Eric Bron | 2011/03/01 08:34 AM |
erratum | Eric Bron | 2011/03/01 08:54 AM |
detour on terminology | Nicolas Capens | 2011/03/10 07:39 AM |
detour on terminology | Eric Bron | 2011/03/10 08:50 AM |
anti-FMA != anti-throughput or anti-SG | Nicolas Capens | 2011/02/23 05:12 AM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 10:25 PM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/17 05:51 PM |
Tarantula vector unit well-integrated | Paul A. Clayton | 2011/02/17 11:38 PM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/19 01:17 PM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 01:09 AM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/20 08:55 AM |
anti-FMA != anti-throughput or anti-SG | David Kanter | 2011/02/20 12:39 PM |
anti-FMA != anti-throughput or anti-SG | EduardoS | 2011/02/20 01:35 PM |
anti-FMA != anti-throughput or anti-SG | Megol | 2011/02/21 07:12 AM |
anti-FMA != anti-throughput or anti-SG | anon | 2011/02/17 09:44 PM |
anti-FMA != anti-throughput or anti-SG | Michael S | 2011/02/18 05:20 AM |
one more anti-FMA flame. By me. | Eric Bron | 2011/02/17 07:24 AM |
thanks | Michael S | 2011/02/17 03:56 PM |
CPUs are latency optimized | EduardoS | 2011/02/15 12:24 PM |
SwiftShader SNB test | Eric Bron | 2011/02/15 02:46 PM |
SwiftShader NHM test | Eric Bron | 2011/02/15 03:50 PM |
SwiftShader SNB test | Nicolas Capens | 2011/02/16 11:06 PM |
SwiftShader SNB test | Eric Bron | 2011/02/17 12:21 AM |
SwiftShader SNB test | Eric Bron | 2011/02/22 09:32 AM |
SwiftShader SNB test 2nd run | Eric Bron | 2011/02/22 09:51 AM |
SwiftShader SNB test 2nd run | Nicolas Capens | 2011/02/23 01:14 PM |
SwiftShader SNB test 2nd run | Eric Bron | 2011/02/23 01:42 PM |
Win7SP1 out but no AVX hype? | Michael S | 2011/02/24 02:14 AM |
Win7SP1 out but no AVX hype? | Eric Bron | 2011/02/24 02:39 AM |
CPUs are latency optimized | Eric Bron | 2011/02/15 07:02 AM |
CPUs are latency optimized | EduardoS | 2011/02/11 02:40 PM |
CPU only rendering - not a long way off | Nicolas Capens | 2011/02/07 05:45 AM |
CPU only rendering - not a long way off | David Kanter | 2011/02/07 11:09 AM |
CPU only rendering - not a long way off | anonymous | 2011/02/07 09:25 PM |
Sandy Bridge IGP EUs | David Kanter | 2011/02/07 10:22 PM |
Sandy Bridge IGP EUs | Hannes | 2011/02/08 04:59 AM |
SW Rasterization - Why? | Seni | 2011/02/02 01:53 PM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/10 02:12 PM |
Market reasons to ditch the IGP | Seni | 2011/02/11 04:42 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/16 03:29 AM |
Market reasons to ditch the IGP | Seni | 2011/02/16 12:39 PM |
An excellent post! | David Kanter | 2011/02/16 02:18 PM |
CPUs clock higher | Moritz | 2011/02/17 07:06 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/18 05:22 PM |
Market reasons to ditch the IGP | IntelUser2000 | 2011/02/18 06:20 PM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/21 01:42 PM |
Bad data (repeated) | David Kanter | 2011/02/21 11:21 PM |
Bad data (repeated) | none | 2011/02/22 02:04 AM |
13W or 8W? | Foo_ | 2011/02/22 05:00 AM |
13W or 8W? | Linus Torvalds | 2011/02/22 07:58 AM |
13W or 8W? | David Kanter | 2011/02/22 10:33 AM |
13W or 8W? | Mark Christiansen | 2011/02/22 01:47 PM |
Bigger picture | Nicolas Capens | 2011/02/24 05:33 PM |
Bigger picture | Nicolas Capens | 2011/02/24 07:06 PM |
20+ Watt | Nicolas Capens | 2011/02/24 07:18 PM |
<20W | David Kanter | 2011/02/25 12:13 PM |
>20W | Nicolas Capens | 2011/03/08 06:34 PM |
IGP is 3X more efficient | David Kanter | 2011/03/08 09:53 PM |
IGP is 3X more efficient | Eric Bron | 2011/03/09 01:44 AM |
>20W | Eric Bron | 2011/03/09 02:48 AM |
Specious data and claims are still specious | David Kanter | 2011/02/25 01:38 AM |
IGP power consumption, LRB samplers | Nicolas Capens | 2011/03/08 05:24 PM |
IGP power consumption, LRB samplers | EduardoS | 2011/03/08 05:52 PM |
IGP power consumption, LRB samplers | Rohit | 2011/03/09 06:42 AM |
Market reasons to ditch the IGP | none | 2011/02/22 01:58 AM |
Market reasons to ditch the IGP | Nicolas Capens | 2011/02/24 05:43 PM |
Market reasons to ditch the IGP | slacker | 2011/02/22 01:32 PM |
Market reasons to ditch the IGP | Seni | 2011/02/18 08:51 PM |
Correction - 28 comparators, not 36. (NT) | Seni | 2011/02/18 09:03 PM |
Market reasons to ditch the IGP | Gabriele Svelto | 2011/02/19 12:49 AM |
Market reasons to ditch the IGP | Seni | 2011/02/19 10:59 AM |
Market reasons to ditch the IGP | Exophase | 2011/02/20 09:43 AM |
Market reasons to ditch the IGP | EduardoS | 2011/02/19 09:13 AM |
Market reasons to ditch the IGP | Seni | 2011/02/19 10:46 AM |
The next revolution | Nicolas Capens | 2011/02/22 02:33 AM |
The next revolution | Gabriele Svelto | 2011/02/22 08:15 AM |
The next revolution | Eric Bron | 2011/02/22 08:48 AM |
The next revolution | Nicolas Capens | 2011/02/23 06:39 PM |
The next revolution | Gabriele Svelto | 2011/02/23 11:43 PM |
GPGPU content creation (or lack of it) | Nicolas Capens | 2011/02/28 06:39 AM |
GPGPU content creation (or lack of it) | The market begs to differ | 2011/03/01 05:32 AM |
GPGPU content creation (or lack of it) | Nicolas Capens | 2011/03/09 08:14 PM |
GPGPU content creation (or lack of it) | Gabriele Svelto | 2011/03/10 12:01 AM |
The market begs to differ | Gabriele Svelto | 2011/03/01 05:33 AM |
The next revolution | Anon | 2011/02/24 01:15 AM |
The next revolution | Nicolas Capens | 2011/02/28 01:34 PM |
The next revolution | Seni | 2011/02/22 01:02 PM |
The next revolution | Gabriele Svelto | 2011/02/23 05:27 AM |
The next revolution | Seni | 2011/02/23 08:03 AM |
The next revolution | Nicolas Capens | 2011/02/24 05:11 AM |
The next revolution | Seni | 2011/02/24 07:45 PM |
IGP sampler count | Nicolas Capens | 2011/03/03 04:19 AM |
Latency and throughput optimized cores | Nicolas Capens | 2011/03/07 02:28 PM |
The real reason no IGP /CPU converge. | Jouni Osmala | 2011/03/07 10:34 PM |
Still converging | Nicolas Capens | 2011/03/13 02:08 PM |
Homogeneous CPU advantages | Nicolas Capens | 2011/03/07 11:12 PM |
Homogeneous CPU advantages | Seni | 2011/03/08 08:23 AM |
Homogeneous CPU advantages | David Kanter | 2011/03/08 10:16 AM |
Homogeneous CPU advantages | Brett | 2011/03/09 02:37 AM |
Homogeneous CPU advantages | Jouni Osmala | 2011/03/08 11:27 PM |
SW Rasterization | firsttimeposter | 2011/02/03 10:18 PM |
SW Rasterization | Nicolas Capens | 2011/02/04 03:48 AM |
SW Rasterization | Eric Bron | 2011/02/04 04:14 AM |
SW Rasterization | Nicolas Capens | 2011/02/04 07:36 AM |
SW Rasterization | Eric Bron | 2011/02/04 07:42 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/26 02:23 AM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/02/04 03:31 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/05 07:46 PM |
Sandy Bridge CPU article online | Gabriele Svelto | 2011/02/06 05:20 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/02/06 05:07 PM |
Sandy Bridge CPU article online | arch.comp | 2011/01/06 09:58 PM |
Sandy Bridge CPU article online | Seni | 2011/01/07 09:25 AM |
Sandy Bridge CPU article online | Michael S | 2011/01/05 03:28 AM |
Sandy Bridge CPU article online | Nicolas Capens | 2011/01/05 05:06 AM |
permuting vector elements (yet again) | hobold | 2011/01/05 04:15 PM |
permuting vector elements (yet again) | Nicolas Capens | 2011/01/06 05:11 AM |
Sandy Bridge CPU article online | Eric Bron | 2011/01/05 11:46 AM |
wow ...! | hobold | 2011/01/05 04:19 PM |
wow ...! | Nicolas Capens | 2011/01/05 05:11 PM |
wow ...! | Eric Bron | 2011/01/05 09:46 PM |
compress LUT | Eric Bron | 2011/01/05 10:05 PM |
wow ...! | Michael S | 2011/01/06 01:25 AM |
wow ...! | Nicolas Capens | 2011/01/06 05:26 AM |
wow ...! | Eric Bron | 2011/01/06 08:08 AM |
wow ...! | Nicolas Capens | 2011/01/07 06:19 AM |
wow ...! | Steve Underwood | 2011/01/07 09:53 PM |
saturation | hobold | 2011/01/08 09:25 AM |
saturation | Steve Underwood | 2011/01/08 11:38 AM |
saturation | Michael S | 2011/01/08 12:05 PM |
128 bit floats | Brett | 2011/01/08 12:39 PM |
128 bit floats | Michael S | 2011/01/08 01:10 PM |
128 bit floats | Anil Maliyekkel | 2011/01/08 02:46 PM |
128 bit floats | Kevin G | 2011/02/27 10:15 AM |
128 bit floats | hobold | 2011/02/27 03:42 PM |
128 bit floats | Ian Ollmann | 2011/02/28 03:56 PM |
OpenCL FP accuracy | hobold | 2011/03/01 05:45 AM |
OpenCL FP accuracy | anon | 2011/03/01 07:03 PM |
OpenCL FP accuracy | hobold | 2011/03/02 02:53 AM |
OpenCL FP accuracy | Eric Bron | 2011/03/02 06:10 AM |
pet project | hobold | 2011/03/02 08:22 AM |
pet project | Anon | 2011/03/02 08:10 PM |
pet project | hobold | 2011/03/03 03:57 AM |
pet project | Eric Bron | 2011/03/03 01:29 AM |
pet project | hobold | 2011/03/03 04:14 AM |
pet project | Eric Bron | 2011/03/03 02:10 PM |
pet project | hobold | 2011/03/03 03:04 PM |
OpenCL and AMD | Vincent Diepeveen | 2011/03/07 12:44 PM |
OpenCL and AMD | Eric Bron | 2011/03/08 01:05 AM |
OpenCL and AMD | Vincent Diepeveen | 2011/03/08 07:27 AM |
128 bit floats | Michael S | 2011/02/27 03:46 PM |
128 bit floats | Anil Maliyekkel | 2011/02/27 05:14 PM |
saturation | Steve Underwood | 2011/01/17 03:42 AM |
wow ...! | hobold | 2011/01/06 04:05 PM |
Ring | Moritz | 2011/01/20 09:51 PM |
Ring | Antti-Ville Tuunainen | 2011/01/21 11:25 AM |
Ring | Moritz | 2011/01/23 12:38 AM |
Ring | Michael S | 2011/01/23 03:04 AM |
So fast | Moritz | 2011/01/23 06:57 AM |
So fast | David Kanter | 2011/01/23 09:05 AM |
Sandy Bridge CPU (L1D cache) | Gordon Ward | 2011/09/09 01:47 AM |
Sandy Bridge CPU (L1D cache) | David Kanter | 2011/09/09 03:19 PM |
Sandy Bridge CPU (L1D cache) | EduardoS | 2011/09/09 07:53 PM |
Sandy Bridge CPU (L1D cache) | Paul A. Clayton | 2011/09/10 04:12 AM |
Sandy Bridge CPU (L1D cache) | Michael S | 2011/09/10 08:41 AM |
Sandy Bridge CPU (L1D cache) | EduardoS | 2011/09/10 10:17 AM |
Address Ports on Sandy Bridge Scheduler | Victor | 2011/10/16 05:40 AM |
Address Ports on Sandy Bridge Scheduler | EduardoS | 2011/10/16 06:45 PM |
Address Ports on Sandy Bridge Scheduler | Megol | 2011/10/17 08:20 AM |
Address Ports on Sandy Bridge Scheduler | Victor | 2011/10/18 04:34 PM |
Benefits of early scheduling | Paul A. Clayton | 2011/10/18 05:53 PM |
Benefits of early scheduling | Victor | 2011/10/19 04:58 PM |
Consistency and invalidation ordering | Paul A. Clayton | 2011/10/20 03:43 AM |
Address Ports on Sandy Bridge Scheduler | John Upcroft | 2011/10/21 03:16 PM |
Address Ports on Sandy Bridge Scheduler | David Kanter | 2011/10/22 09:49 AM |
Address Ports on Sandy Bridge Scheduler | John Upcroft | 2011/10/26 12:24 PM |
Store TLB look-up at commit? | Paul A. Clayton | 2011/10/26 07:30 PM |
Store TLB look-up at commit? | Richard Scott | 2011/10/26 08:40 PM |
Just a guess | Paul A. Clayton | 2011/10/27 12:54 PM |