AMD CPU speculation... and expert conjecture

[juanrga]

The fault is on Microsoft part. You don't need to download and apply patches on linux, for instance.

No, Linux just releases a new kernel to accomplish the same exact thing. Or the package that contains wherever scheduler is being used gets updated.

Who said you that AMD wasn't working with MSFT to get the issue resolved prior to product launch? You are assuming too much.

Based on the fact BD was in development for what, FIVE YEARS, and a relatively simple change to the scheduler wasn't introduced, even after a major version change (Vista) and an additional minor version change (7) to the kernel was released during the time BD was in development? So yeah, that's telling me either MSFT was too lazy to implement/test a few line fix for their second largest CPU vendor, or that AMD simply didn't bother to go to MSFT ahead of time.

The second is more believable.

The popular idea that GDDR5 latencies are astronomic and will affect CPU performance is a myth. Latencies are essentially the same and outperformed by the bandwidth gain.

Astronomic? No. But even minor latency degregation can force the CPU to wait around doing nothing, which is the last thing you want the CPU doing. And extra bandwidth doesn't help if your application is only asking for a few KB worth of data. If that trend happens enough, then it will show in the final performance.

Releasing a new kernel for supporting a new architecture is not the same than releasing fixes to patch the unfixable.

Therefore the unix/linux community had absolutely no problem with AMD, but when Microsoft has serious problems and released buggy hotfixes to fix that bad scheduler, the problem is... AMD.

According to you, the well-known fact that AMD chips work better under linux has nothing to do with Microsoft releasing mediocre products or only caring about Intel (Wintel).

DDR3 typical latencies 10-15 ns. GDDR5 typical latencies 10-12 ns. Myth: GDDR5 has very poor latencies...

This myth seems to have been initiated by Intel fanboys when Sony presented its AMD-powered console. You can find lots of posters in forums and blogs claiming that "PC is better", that GDDR5 is not used in gaming PCs (aka they did mean Wintel PCs) because drops CPU performance.

So many AMD hate around...

 

[blackkstar]

The fault is on Microsoft part. You don't need to download and apply patches on linux, for instance.

No, Linux just releases a new kernel to accomplish the same exact thing. Or the package that contains wherever scheduler is being used gets updated.

Who said you that AMD wasn't working with MSFT to get the issue resolved prior to product launch? You are assuming too much.

Based on the fact BD was in development for what, FIVE YEARS, and a relatively simple change to the scheduler wasn't introduced, even after a major version change (Vista) and an additional minor version change (7) to the kernel was released during the time BD was in development? So yeah, that's telling me either MSFT was too lazy to implement/test a few line fix for their second largest CPU vendor, or that AMD simply didn't bother to go to MSFT ahead of time.

The second is more believable.

The popular idea that GDDR5 latencies are astronomic and will affect CPU performance is a myth. Latencies are essentially the same and outperformed by the bandwidth gain.

Astronomic? No. But even minor latency degregation can force the CPU to wait around doing nothing, which is the last thing you want the CPU doing. And extra bandwidth doesn't help if your application is only asking for a few KB worth of data. If that trend happens enough, then it will show in the final performance.

Releasing a new kernel for supporting a new architecture is not the same than releasing fixes to patch the unfixable.

Therefore the unix/linux community had absolutely no problem with AMD, but when Microsoft has serious problems and released buggy hotfixes to fix that bad scheduler, the problem is... AMD.

According to you, the well-known fact that AMD chips work better under linux has nothing to do with Microsoft releasing mediocre products or only caring about Intel (Wintel).

DDR3 typical latencies 10-15 ns. GDDR5 typical latencies 10-12 ns. Myth: GDDR5 has very poor latencies...

This myth seems to have been initiated by Intel fanboys when Sony presented its AMD-powered console. You can find lots of posters in forums and blogs claiming that "PC is better", that GDDR5 is not used in gaming PCs (aka they did mean Wintel PCs) because drops CPU performance.

So many AMD hate around...

It isn't very hard to figure out that this is Microsoft's fault. I don't know why you can't get people to see this.

AMD submitted changes for their CPUs to GCC and everything, and they showed up, just fine.

AMD then submits changes to Microsoft and it ends up a disaster.

Had this been AMD's fault, the Linux versions would be just as bad. AMD told MS what needed to be done, and MS half-assed it because they weren't going to make money off of an AMD patch. "Hey we improved performance for AMD FX CPUS!" isn't going to change someone's mind and make them go, "well, I was thinking about buying Windows but now that there's this patch, I'm definitely buying Windows!"

People need to open up to the idea of looking at things from a company's perspective. If you were MS and AMD showed up and said "please help our CPUs run faster by changing your kernel" you'd probably look at the folks you'd have to pay to make it happen, publishing the patch, and everything and then not caring at all about actually doing it.

And then compare to Linux where FX runs absolutely great (I'm on Gentoo right now, actually) where AMD pretty much posted patches and they got added, and it's not hard to see who is at fault.

The company who only cares about profits getting nagged to change their kernel for something that would not make the money and the patch turned out bad, while the open source community who doesn't care about profits had things turn out well.

 

[jdwii]

Windows just works. Linux is optimized since the kernel was designed to scale well on multi-core supercomputers. Moreover, the Windows scheduler doesn't understand well CMT.

And that's AMD's fault, and one I personally noted as a potential problem back in the beginning of the BD speculation thread. Windows did what it was designed to do: Use a non-HTT core as a normal CPU. But because using the second core of a BD module incurs a performance penalty, this resulted in BD performing even worse then some of us expected.

I even gave a simple fix that could be implemented without a windows change: Enable the HTT bit via a BIOS update, so Windows would treat a CMT core the same way it treats HTT (avoid using unless heavy workload). While not "perfect", it would have avoided the months wait for a windows patch.

The real question should be "Why wasn't AMD working with MSFT to get the issue resolved prior to product launch?".

Again, I don't worry about the latency myth.

Its not a myth; you can only execute on data that you have access to. And if it takes a few extra ns to get the data you need, guess what? Your CPU is idling, doing nothing, or worse (from a benchmarking perspective), context-switching to some other task, causing your application to wait even longer to execute.

For anything memory intensive? GDDR5 is a huge speedup; potentially 200%+ performance gains. I'm more worried about those low level system tasks, that only need to read a few KB at a time, and the leeching the higher baseline latency will have on overall performance. Whether that extra latency is noticeable in usage I can't say, but I can say I've worked on systems where higher bandwidth, but higher latency, caused a subset of tasks to have lower absolute performance. And I wouldn't be shocked if that's the case here as well.

The fault is on Microsoft part. You don't need to download and apply patches on linux, for instance.

And when Microsoft decided to released its first hotfix it was buggy and had to release another to fix the hotfix. Amazing!

Who said you that AMD wasn't working with MSFT to get the issue resolved prior to product launch? You are assuming too much.

The popular idea that GDDR5 latencies are astronomic and will affect CPU performance is a myth. Latencies are essentially the same and outperformed by the bandwidth gain.

Sorry to tell you but these hotfixes only improved performance by 3-5% not nearly enough to make bulldozer relevant in the high performance field(horrible design to begin with Latency is most important in a CPU and the module design raises latency)

That is why this design was originally shut down many engineers at Amd didn't want this to happen. Amd advertises Serial performance for their APU's but they don't offer the best of 2 worlds this design was a bad choice.

 

[palladin9479]

Spoiler

Could HSA be the reason AMD may not make a 8 core AM3+ steamroller, if its as good as it could be you may not want to waste space on CPU cores when GPU cores will make more difference. Just a thought.

That is my point. Why would AMD waste die space, TDP, and money with extra SR cores for parallel workloads, when GCN CUs are much much faster at parallel workloads?

[strike]8 SR cores[/strike] --> 4 SR cores + 8 GCN-CU cores

APUs maintain the same "moar cores" motto, except that cores of one kind are being substituted by cores of a more efficient kind.

This is High Performance Computing design coming to the desk. Curious readers can take a look to modern supercomputers such as Titan and see that the supercomputer uses GPUs (not CPUs) for the most heavy parallel tasks

http://www.olcf.ornl.gov/titan/

That's not how that works, not remotely. Stop using "cores" as a generic reference to a CPU. Modern CPU's are composed of several processors that each do a separate function, their aggregate capabilities are then lumped together in what we call "core". Perfect example is x87, SSE and other SIMD units. Those are not part of x86, their referenced and addressed separately, have separate non-x86 registers and in the case of SIMD are actual special purpose RISC processors. "HSA" is just a term AMD (and others) is using to reference putting multiple processors of different uArch's on the same system. By exposing the ports / irq's (yes we're getting to this level) / address's of those different CPU's to the OS we can then run code as required. Code compiled for one uArch will not run on another, so there is no magical statement like what you referenced above.

GPUs are just special purpose CPU's, they have registers and run instructions like anything else. Their uArch and ISA is designed around doing the kinds of processing that is involved with rasterization, geometry and lighting effects yet their still processors. You can get a GPU to add 2 and 2 together and produce 4, will be slow and wasteful compared to using an integer processor but it will work. There is currently a ton of inefficiencies when working with these special purpose coprocessors, moving the data in and out of main memory, crunching it and then deciding what to do with the result.

HSA is about reducing / removing those inefficiencies, and streamlining the process of running code on an integer processor (what a CPU is) while also running code on a vector processor (what a GPU is). Basically making GPGPU / OpenCL type languages much faster and having less layers of abstraction / inefficiencies.

In the first place, I have absolutely no idea of from where you got the idea that I am using "cores" as a generic reference to a CPU, because I am not.

In the second place, I would like to know from where you got the idea behind your "Code compiled for one uArch will not run on another, so there is no magical statement like what you referenced above" because nowhere I said that code complied for an uarch will work for another. At contrary, I have been giving just the contrary idea in this thread, e.g. when discussing "bvder2" compiler flags for Piledriver.

You consider a GPU a special kind of CPU, but others don't. It is customary to differentiate between CPU and GPU. It is not strange, therefore, that the people who designed the Titan supercomputer makes this distinction as well. See above link:

The combination of CPUs and GPUs will allow Titan and future systems to overcome power and space limitations inherent in previous generations of high-performance computers.

Because they handle hundreds of calculations simultaneously, GPUs can go through many more than CPUs in a given time. Yet they draw only modestly more electricity. By relying on its 299,008 CPU cores to guide simulations and allowing its Tesla K20 GPUs, which are based on NVIDIA's next-generation Kepler architecture to do the heavy lifting, Titan will be approximately ten times more powerful than its predecessor, Jaguar, while occupying the same space and drawing essentially the same level of power.

My main point is that AMD is translating this hybrid architecture used in top supercomputers to the server/desktop/mobile space with HSA APUs

Note as AMD also differentiates between CPU and GPU.

HSA is more than "basically making GPGPU / OpenCL type languages much faster". HSA blurs the distinction between different kind of cores by providing an unified approach both at hardware and software level. In principle, developers will select the more optimal cores for each kind of workload: serial --> CPU cores; parallel --> GPU cores. But there is an extra possibility opened by HSA to use the GPU to help the CPU in serial tasks (e.g., when the CPU was bottlenecked) and vice versa.

Only if someone doesn't have an in depth understanding of transistors and how processing is done. There is technically no difference between a "CPU" and a "GPU", they are both integrated electronics that use binary math to perform computations. The term "GPU" was coined by Nvidia when they integrated transition, lighting and geometry capabilities into their frame buffers. It was a marketing term used to differentiate their advanced processor from the competitions.

The concept of processing and processors needs to be fully understood before we can go any further. Your pocket calculator has a processor in it, its very basic with a limited range of instructions it can accept, yet it is still a processor. The processors used on modern graphics cards are just vector processors vs scalar processors that do integer work.

http://en.wikipedia.org/wiki/Vector_processor

The concept of using vector processors to do work has been around for decades. Using a combination of scalar and vector processors has been around just as long, early super computers used to do this.

What AMD is doing is just codifying a methodology for multiple non-uniform processors to communicate with each other. This is similar to what Intel did with the MMX and later SSE extensions, hey added it to the x86 ISA rather then make it an open extendable standard. Technically this is already happening as the "FPU" in modern CPU's is actually a separate co-processor that's operates in the same memory space. So now you will have three or more processors working together, the CPU, FPU (SIMD engine) and "other" (no official industry name has really risen up yet) and exchanging data / operations.

This is where I take issue

That is my point. Why would AMD waste die space, TDP, and money with extra SR cores for parallel workloads, when GCN CUs are much much faster at parallel workloads?

[strike]8 SR cores[/strike] --> 4 SR cores + 8 GCN-CU cores

That is incorrect. Code designed for / compiled on x86 will not auto-magically run on non-x86 processor. Those 8 SR "cores" would actually be faster with that workload. It would require a separate workload to be designed / compiled to get any advantage at all out of the additional co-processors.

This is one of the reasons I feel everyone should learn some ASM, it's really an eye opened to exactly how processors work and interact with everything else.

Some info about the above

http://en.wikipedia.org/wiki/Heterogeneous_computing
http://en.wikipedia.org/wiki/Asymmetric_multiprocessing

 

[juanrga]

The fault is on Microsoft part. You don't need to download and apply patches on linux, for instance.

No, Linux just releases a new kernel to accomplish the same exact thing. Or the package that contains wherever scheduler is being used gets updated.

Who said you that AMD wasn't working with MSFT to get the issue resolved prior to product launch? You are assuming too much.

Based on the fact BD was in development for what, FIVE YEARS, and a relatively simple change to the scheduler wasn't introduced, even after a major version change (Vista) and an additional minor version change (7) to the kernel was released during the time BD was in development? So yeah, that's telling me either MSFT was too lazy to implement/test a few line fix for their second largest CPU vendor, or that AMD simply didn't bother to go to MSFT ahead of time.

The second is more believable.

The popular idea that GDDR5 latencies are astronomic and will affect CPU performance is a myth. Latencies are essentially the same and outperformed by the bandwidth gain.

Astronomic? No. But even minor latency degregation can force the CPU to wait around doing nothing, which is the last thing you want the CPU doing. And extra bandwidth doesn't help if your application is only asking for a few KB worth of data. If that trend happens enough, then it will show in the final performance.

Releasing a new kernel for supporting a new architecture is not the same than releasing fixes to patch the unfixable.

Therefore the unix/linux community had absolutely no problem with AMD, but when Microsoft has serious problems and released buggy hotfixes to fix that bad scheduler, the problem is... AMD.

According to you, the well-known fact that AMD chips work better under linux has nothing to do with Microsoft releasing mediocre products or only caring about Intel (Wintel).

DDR3 typical latencies 10-15 ns. GDDR5 typical latencies 10-12 ns. Myth: GDDR5 has very poor latencies...

This myth seems to have been initiated by Intel fanboys when Sony presented its AMD-powered console. You can find lots of posters in forums and blogs claiming that "PC is better", that GDDR5 is not used in gaming PCs (aka they did mean Wintel PCs) because drops CPU performance.

So many AMD hate around...

It isn't very hard to figure out that this is Microsoft's fault. I don't know why you can't get people to see this.

AMD submitted changes for their CPUs to GCC and everything, and they showed up, just fine.

AMD then submits changes to Microsoft and it ends up a disaster.

Had this been AMD's fault, the Linux versions would be just as bad. AMD told MS what needed to be done, and MS half-assed it because they weren't going to make money off of an AMD patch. "Hey we improved performance for AMD FX CPUS!" isn't going to change someone's mind and make them go, "well, I was thinking about buying Windows but now that there's this patch, I'm definitely buying Windows!"

People need to open up to the idea of looking at things from a company's perspective. If you were MS and AMD showed up and said "please help our CPUs run faster by changing your kernel" you'd probably look at the folks you'd have to pay to make it happen, publishing the patch, and everything and then not caring at all about actually doing it.

And then compare to Linux where FX runs absolutely great (I'm on Gentoo right now, actually) where AMD pretty much posted patches and they got added, and it's not hard to see who is at fault.

The company who only cares about profits getting nagged to change their kernel for something that would not make the money and the patch turned out bad, while the open source community who doesn't care about profits had things turn out well.

Agree. In fact, Microsoft had to fix its fix!

Windows just works. Linux is optimized since the kernel was designed to scale well on multi-core supercomputers. Moreover, the Windows scheduler doesn't understand well CMT.

And that's AMD's fault, and one I personally noted as a potential problem back in the beginning of the BD speculation thread. Windows did what it was designed to do: Use a non-HTT core as a normal CPU. But because using the second core of a BD module incurs a performance penalty, this resulted in BD performing even worse then some of us expected.

I even gave a simple fix that could be implemented without a windows change: Enable the HTT bit via a BIOS update, so Windows would treat a CMT core the same way it treats HTT (avoid using unless heavy workload). While not "perfect", it would have avoided the months wait for a windows patch.

The real question should be "Why wasn't AMD working with MSFT to get the issue resolved prior to product launch?".

Again, I don't worry about the latency myth.

Its not a myth; you can only execute on data that you have access to. And if it takes a few extra ns to get the data you need, guess what? Your CPU is idling, doing nothing, or worse (from a benchmarking perspective), context-switching to some other task, causing your application to wait even longer to execute.

For anything memory intensive? GDDR5 is a huge speedup; potentially 200%+ performance gains. I'm more worried about those low level system tasks, that only need to read a few KB at a time, and the leeching the higher baseline latency will have on overall performance. Whether that extra latency is noticeable in usage I can't say, but I can say I've worked on systems where higher bandwidth, but higher latency, caused a subset of tasks to have lower absolute performance. And I wouldn't be shocked if that's the case here as well.

The fault is on Microsoft part. You don't need to download and apply patches on linux, for instance.

And when Microsoft decided to released its first hotfix it was buggy and had to release another to fix the hotfix. Amazing!

Who said you that AMD wasn't working with MSFT to get the issue resolved prior to product launch? You are assuming too much.

The popular idea that GDDR5 latencies are astronomic and will affect CPU performance is a myth. Latencies are essentially the same and outperformed by the bandwidth gain.

Sorry to tell you but these hotfixes only improved performance by 3-5% not nearly enough to make bulldozer relevant in the high performance field(horrible design to begin with Latency is most important in a CPU and the module design raises latency)

That is why this design was originally shut down many engineers at Amd didn't want this to happen. Amd advertises Serial performance for their APU's but they don't offer the best of 2 worlds this design was a bad choice.

Bulldozer was not the brightest design made by AMD, but the hotfixes by Microsoft were very far from optimal. My position is well summarized in the next:

After their first attempt to improve Bulldozer performance through a Windows 7 scheduler was quickly pulled due to performance issues, Microsoft is yet again trying by introducing a new core scheduler update.

As we reported in our original Bulldozer review, AMD made it abundantly apparent that Bulldozer couldn’t realize its full potential under a Windows 7 environment. Their reasoning behind these claims was directed towards Windows 7′s core scheduling which just couldn’t take advantage of the new, advanced architecture. Windows 8 is supposed to do away with many of these issues through the introduction of a new scheduler but Microsoft has now rolled out another update (the first one caused performance issues and was pulled) which is supposed to grant the Bulldozer architecture additional performance improvements under the their current operating system.

[...]

Some of you may remember that AMD FX processors use a unique dual-core module architecture codenamed “Bulldozer”, which current versions of Windows® 7 were not specifically architected to utilize. In essence, for those with an AMD FX-8150 Processor, for example, Windows 7 sees the eight available cores and randomly assigns threads to them.

In initial testing of the upcoming Windows 8 operating system, we’ve seen performance improvements of up to 10% in some applications, when compared to Windows 7. This is because the system correctly recognizes the AMD FX processor architecture and cores. Thanks to close collaboration between Microsoft and AMD, Microsoft recently completed back-porting some of the Windows 8 scheduler code for AMD FX processors into a hotfix for Windows 7.

http://www.hardwarecanucks.com/news/cpu/microsoft-tries-again-second-win-7-bulldozer-hotfix-now-available/

Again: there was no problems in other operative systems.

 

[sarinaide]

I see the same stuff over and over and its giving me a headache. Multi-processing, Hetrogeneous computing, OpenCL while they all share commonality they are all by and large antiquated and the reason why they are still used is because hardware and software is most optimised for it. It is also naive to accept that this standard will be the same forever as we know it is antiquated and needs more efficient methodologies cue the issue here, yes the coders here know what they learned at universities but that is all they really know, then there are those that are accredited with changing the landscape of what is known. AMD would not commit to HSA like the others if it was going to end up in the same result. I won't comment on the intricacies as I leave that to those who are in the know of such but nothing is ever fixed or static and is there just a incling of the thought that maybe there are those that actually do know how to more streamline multi-processing, Heterogeneous compute methods to actually be notably faster than the standards of today? Is there any possibility that maybe someone has figured it out and probably not by mere coincidence but years of research? Or do we exist in this bubble that single thread legacy compute standards and all it entails is going to be around until man kills himself or some other vis major ends life as we know it?

 

[juanrga]

Spoiler

Could HSA be the reason AMD may not make a 8 core AM3+ steamroller, if its as good as it could be you may not want to waste space on CPU cores when GPU cores will make more difference. Just a thought.

That is my point. Why would AMD waste die space, TDP, and money with extra SR cores for parallel workloads, when GCN CUs are much much faster at parallel workloads?

[strike]8 SR cores[/strike] --> 4 SR cores + 8 GCN-CU cores

APUs maintain the same "moar cores" motto, except that cores of one kind are being substituted by cores of a more efficient kind.

This is High Performance Computing design coming to the desk. Curious readers can take a look to modern supercomputers such as Titan and see that the supercomputer uses GPUs (not CPUs) for the most heavy parallel tasks

http://www.olcf.ornl.gov/titan/

That's not how that works, not remotely. Stop using "cores" as a generic reference to a CPU. Modern CPU's are composed of several processors that each do a separate function, their aggregate capabilities are then lumped together in what we call "core". Perfect example is x87, SSE and other SIMD units. Those are not part of x86, their referenced and addressed separately, have separate non-x86 registers and in the case of SIMD are actual special purpose RISC processors. "HSA" is just a term AMD (and others) is using to reference putting multiple processors of different uArch's on the same system. By exposing the ports / irq's (yes we're getting to this level) / address's of those different CPU's to the OS we can then run code as required. Code compiled for one uArch will not run on another, so there is no magical statement like what you referenced above.

GPUs are just special purpose CPU's, they have registers and run instructions like anything else. Their uArch and ISA is designed around doing the kinds of processing that is involved with rasterization, geometry and lighting effects yet their still processors. You can get a GPU to add 2 and 2 together and produce 4, will be slow and wasteful compared to using an integer processor but it will work. There is currently a ton of inefficiencies when working with these special purpose coprocessors, moving the data in and out of main memory, crunching it and then deciding what to do with the result.

HSA is about reducing / removing those inefficiencies, and streamlining the process of running code on an integer processor (what a CPU is) while also running code on a vector processor (what a GPU is). Basically making GPGPU / OpenCL type languages much faster and having less layers of abstraction / inefficiencies.

In the first place, I have absolutely no idea of from where you got the idea that I am using "cores" as a generic reference to a CPU, because I am not.

In the second place, I would like to know from where you got the idea behind your "Code compiled for one uArch will not run on another, so there is no magical statement like what you referenced above" because nowhere I said that code complied for an uarch will work for another. At contrary, I have been giving just the contrary idea in this thread, e.g. when discussing "bvder2" compiler flags for Piledriver.

You consider a GPU a special kind of CPU, but others don't. It is customary to differentiate between CPU and GPU. It is not strange, therefore, that the people who designed the Titan supercomputer makes this distinction as well. See above link:

The combination of CPUs and GPUs will allow Titan and future systems to overcome power and space limitations inherent in previous generations of high-performance computers.

Because they handle hundreds of calculations simultaneously, GPUs can go through many more than CPUs in a given time. Yet they draw only modestly more electricity. By relying on its 299,008 CPU cores to guide simulations and allowing its Tesla K20 GPUs, which are based on NVIDIA's next-generation Kepler architecture to do the heavy lifting, Titan will be approximately ten times more powerful than its predecessor, Jaguar, while occupying the same space and drawing essentially the same level of power.

My main point is that AMD is translating this hybrid architecture used in top supercomputers to the server/desktop/mobile space with HSA APUs

Note as AMD also differentiates between CPU and GPU.

HSA is more than "basically making GPGPU / OpenCL type languages much faster". HSA blurs the distinction between different kind of cores by providing an unified approach both at hardware and software level. In principle, developers will select the more optimal cores for each kind of workload: serial --> CPU cores; parallel --> GPU cores. But there is an extra possibility opened by HSA to use the GPU to help the CPU in serial tasks (e.g., when the CPU was bottlenecked) and vice versa.

Only if someone doesn't have an in depth understanding of transistors and how processing is done. There is technically no difference between a "CPU" and a "GPU", they are both integrated electronics that use binary math to perform computations. The term "GPU" was coined by Nvidia when they integrated transition, lighting and geometry capabilities into their frame buffers. It was a marketing term used to differentiate their advanced processor from the competitions.

Exactly. I don't have a deep understanding. AMD doesn't have a deep understanding. The people who made the Titan Supercomputer doesn't have a deep understanding. This is the reason why we continue to use the terms CPU and GPU. Moreover, I don't know the history behind VPU and GPU terms.

Now that you made your point, let me say that I will continue using the terms CPU and GPU, and others related such as APU, GPGPU... like I have been using up to now.

This is where I take issue

That is my point. Why would AMD waste die space, TDP, and money with extra SR cores for parallel workloads, when GCN CUs are much much faster at parallel workloads?

[strike]8 SR cores[/strike] --> 4 SR cores + 8 GCN-CU cores

That is incorrect. Code designed for / compiled on x86 will not auto-magically run on non-x86 processor. Those 8 SR "cores" would actually be faster with that workload. It would require a separate workload to be designed / compiled to get any advantage at all out of the additional co-processors.

I am not saying that the GPU will run code compiled for the CPU. You already posted this kind of misunderstanding before. I already corrected you. I already mentioned you that the GPU in a HSA APU will be used for compute only with "HSA enabled software", still you insist on misunderstanding me...

 

[gamerk316]

The only thing really that is allowing AMD to keep it's head above water is OpenGL. OpenGL will run slightly better than Direct X, unless you get a higher end Nvidia card (770, 780, or Titan) which will boost the performance greatly of Direct X. The thing that I found the least realistic about games, is the lighting. In almost every game I play, the lighting is very bright compared to reality, no matter what settings you play at. DirectX does a better job at getting darker shades and colors, but at the same time getting better dynamic lighting results so the distortion between light and dark is better, as well as better texture results.

Then again, it is also the problem of how good the user uses Direct X. If it is executed correctly, it will look much more fantastic and beautiful than OpenGL, whilst keeping up with the frame rates of it.

AMD has the performance gain of OpenGL, however, DirectX does look better, and is easier to code for. If they make a more optimized or shorter code for DirectX, it is bound to be the same if not better quality, and run faster and better. CUDA is what helps boost this Direct X performance. Everyone says "it's a marketing gimmick" but its really the architecture of it that gives it advantages for PhysX and Direct X. CUDA is the name given for the architecture units that run the engines. This is literally no different than what AMD uses to power OpenGL better, except they didn't specifically name it.

Uh, no. Graphically, DX and OGL have the capabilities to output the same, exact, picture. OGL is a PITA to code with though. In my opinion, OGL as is currently designed is functionally obsolete, and the API needs a total re-write. But Direct X isn't graphically "superior", just easier to code with.

 

[gamerk316]

Releasing a new kernel for supporting a new architecture is not the same than releasing fixes to patch the unfixable.

Therefore the unix/linux community had absolutely no problem with AMD, but when Microsoft has serious problems and released buggy hotfixes to fix that bad scheduler, the problem is... AMD.

According to you, the well-known fact that AMD chips work better under linux has nothing to do with Microsoft releasing mediocre products or only caring about Intel (Wintel).

To be fair, its worth noting on of the major contributors to the Linux kernel is: AMD. I would hope their CPU had day 1 support, given AMD was the entity that released the patches to support BD. Also worth noting that GCC already had BD optimizations prior to the BD launch, where MSVC didn't. Finally, you have to note the frequent release of updates to the kernel (compared to Windows 2-4 year lifecycle) favors getting more out of architectures over time. I can say BD is probably 20%+ faster now then it was on release for Linux.

Also, funny how AMD did about the same in Linux/Windows at release:

http://www.phoronix.com/scan.php?page=article&item=amd_fx8150_bulldozer&num=6

Looses single threaded, competitive with Nahalem multithreaded, typically looses to SB. Same as Windows basically.

DDR3 typical latencies 10-15 ns. GDDR5 typical latencies 10-12 ns. Myth: GDDR5 has very poor latencies...

This myth seems to have been initiated by Intel fanboys when Sony presented its AMD-powered console. You can find lots of posters in forums and blogs claiming that "PC is better", that GDDR5 is not used in gaming PCs (aka they did mean Wintel PCs) because drops CPU performance.

Funny, I've seen much higher latencies for GDDR5. We'll see at release, but I'd expect a subset of workloads to show a decline in performance.

----------------

Also, just a little historical background, aside from being one of the 2-3 people here who nailed BD's performance prior to release, I'm also the guy who's long held X86 as an arch is simply non-competitive in the low-power (mobile) market, and that Intel's Larabee design (or whatever they are calling it theses days) had no chance of being competitive. I call it the way I see it. And right now, the way I see it, AMD followed the wrong CPU architecture, and that's the way I called it two years ago. Heck, given the move to Trinity/HSA, having lots of cores as the expense of per-core performance makes even LESS sense, given that type of work is best left offloaded to the APU anyways.

The best CPU company right now? Qualcomm. Aside from the fact they are now worth more then Intel, they have the best chance of having constant success in mobile, the one market that is growing at the moment. Sure, they don't have the best performance, but in terms of profit potential, Qualcomm is looking the best right now.

 

[gamerk316]

Spoiler

Could HSA be the reason AMD may not make a 8 core AM3+ steamroller, if its as good as it could be you may not want to waste space on CPU cores when GPU cores will make more difference. Just a thought.

That is my point. Why would AMD waste die space, TDP, and money with extra SR cores for parallel workloads, when GCN CUs are much much faster at parallel workloads?

[strike]8 SR cores[/strike] --> 4 SR cores + 8 GCN-CU cores

APUs maintain the same "moar cores" motto, except that cores of one kind are being substituted by cores of a more efficient kind.

This is High Performance Computing design coming to the desk. Curious readers can take a look to modern supercomputers such as Titan and see that the supercomputer uses GPUs (not CPUs) for the most heavy parallel tasks

http://www.olcf.ornl.gov/titan/

That's not how that works, not remotely. Stop using "cores" as a generic reference to a CPU. Modern CPU's are composed of several processors that each do a separate function, their aggregate capabilities are then lumped together in what we call "core". Perfect example is x87, SSE and other SIMD units. Those are not part of x86, their referenced and addressed separately, have separate non-x86 registers and in the case of SIMD are actual special purpose RISC processors. "HSA" is just a term AMD (and others) is using to reference putting multiple processors of different uArch's on the same system. By exposing the ports / irq's (yes we're getting to this level) / address's of those different CPU's to the OS we can then run code as required. Code compiled for one uArch will not run on another, so there is no magical statement like what you referenced above.

GPUs are just special purpose CPU's, they have registers and run instructions like anything else. Their uArch and ISA is designed around doing the kinds of processing that is involved with rasterization, geometry and lighting effects yet their still processors. You can get a GPU to add 2 and 2 together and produce 4, will be slow and wasteful compared to using an integer processor but it will work. There is currently a ton of inefficiencies when working with these special purpose coprocessors, moving the data in and out of main memory, crunching it and then deciding what to do with the result.

HSA is about reducing / removing those inefficiencies, and streamlining the process of running code on an integer processor (what a CPU is) while also running code on a vector processor (what a GPU is). Basically making GPGPU / OpenCL type languages much faster and having less layers of abstraction / inefficiencies.

In the first place, I have absolutely no idea of from where you got the idea that I am using "cores" as a generic reference to a CPU, because I am not.

In the second place, I would like to know from where you got the idea behind your "Code compiled for one uArch will not run on another, so there is no magical statement like what you referenced above" because nowhere I said that code complied for an uarch will work for another. At contrary, I have been giving just the contrary idea in this thread, e.g. when discussing "bvder2" compiler flags for Piledriver.

You consider a GPU a special kind of CPU, but others don't. It is customary to differentiate between CPU and GPU. It is not strange, therefore, that the people who designed the Titan supercomputer makes this distinction as well. See above link:

The combination of CPUs and GPUs will allow Titan and future systems to overcome power and space limitations inherent in previous generations of high-performance computers.

Because they handle hundreds of calculations simultaneously, GPUs can go through many more than CPUs in a given time. Yet they draw only modestly more electricity. By relying on its 299,008 CPU cores to guide simulations and allowing its Tesla K20 GPUs, which are based on NVIDIA's next-generation Kepler architecture to do the heavy lifting, Titan will be approximately ten times more powerful than its predecessor, Jaguar, while occupying the same space and drawing essentially the same level of power.

My main point is that AMD is translating this hybrid architecture used in top supercomputers to the server/desktop/mobile space with HSA APUs

Note as AMD also differentiates between CPU and GPU.

HSA is more than "basically making GPGPU / OpenCL type languages much faster". HSA blurs the distinction between different kind of cores by providing an unified approach both at hardware and software level. In principle, developers will select the more optimal cores for each kind of workload: serial --> CPU cores; parallel --> GPU cores. But there is an extra possibility opened by HSA to use the GPU to help the CPU in serial tasks (e.g., when the CPU was bottlenecked) and vice versa.

Only if someone doesn't have an in depth understanding of transistors and how processing is done. There is technically no difference between a "CPU" and a "GPU", they are both integrated electronics that use binary math to perform computations. The term "GPU" was coined by Nvidia when they integrated transition, lighting and geometry capabilities into their frame buffers. It was a marketing term used to differentiate their advanced processor from the competitions.

The concept of processing and processors needs to be fully understood before we can go any further. Your pocket calculator has a processor in it, its very basic with a limited range of instructions it can accept, yet it is still a processor. The processors used on modern graphics cards are just vector processors vs scalar processors that do integer work.

http://en.wikipedia.org/wiki/Vector_processor

The concept of using vector processors to do work has been around for decades. Using a combination of scalar and vector processors has been around just as long, early super computers used to do this.

What AMD is doing is just codifying a methodology for multiple non-uniform processors to communicate with each other. This is similar to what Intel did with the MMX and later SSE extensions, hey added it to the x86 ISA rather then make it an open extendable standard. Technically this is already happening as the "FPU" in modern CPU's is actually a separate co-processor that's operates in the same memory space. So now you will have three or more processors working together, the CPU, FPU (SIMD engine) and "other" (no official industry name has really risen up yet) and exchanging data / operations.

This is where I take issue

That is my point. Why would AMD waste die space, TDP, and money with extra SR cores for parallel workloads, when GCN CUs are much much faster at parallel workloads?

[strike]8 SR cores[/strike] --> 4 SR cores + 8 GCN-CU cores

That is incorrect. Code designed for / compiled on x86 will not auto-magically run on non-x86 processor. Those 8 SR "cores" would actually be faster with that workload. It would require a separate workload to be designed / compiled to get any advantage at all out of the additional co-processors.

This is one of the reasons I feel everyone should learn some ASM, it's really an eye opened to exactly how processors work and interact with everything else.

Some info about the above

http://en.wikipedia.org/wiki/Heterogeneous_computing
http://en.wikipedia.org/wiki/Asymmetric_multiprocessing

Yes, but its easier to talk "CPU" and "GPU" due to historical context, or in otherwords, the types of loads both are designed for. But yeah, language is going to be a problem going forward.

And yes, everyone should learn at least some ASM. You really can't talk about code optimization until you have an application to what the code actually DOES internally.

 

[juanrga]

Releasing a new kernel for supporting a new architecture is not the same than releasing fixes to patch the unfixable.

Therefore the unix/linux community had absolutely no problem with AMD, but when Microsoft has serious problems and released buggy hotfixes to fix that bad scheduler, the problem is... AMD.

According to you, the well-known fact that AMD chips work better under linux has nothing to do with Microsoft releasing mediocre products or only caring about Intel (Wintel).

To be fair, its worth noting on of the major contributors to the Linux kernel is: AMD.

What is funny is that Microsoft is one of the top contributors to linux kernel

http://arstechnica.com/business/2012/04/linux-kernel-in-2011-15-million-total-lines-of-code-and-microsoft-is-a-top-contributor/

Also, funny how AMD did about the same in Linux/Windows at release:

http://www.phoronix.com/scan.php?page=article&item=amd_fx8150_bulldozer&num=6

Looses single threaded, competitive with Nahalem multithreaded, typically looses to SB. Same as Windows basically.

But that review was not showing the real Bulldozer performance, unlike what you believe:

Linux users will be able to take full advantage of the Bulldozer architecture sooner than Microsoft Windows customers, which will primarily see the real potential when Windows 8 is released. In the Linux world, there's still some Bulldozer kernel work that's not yet merged and presumably more compiler/kernel optimizations coming, but we will hopefully see all of that merged and ready in time for next spring when Ubuntu 12.04 LTS, Fedora 17, and other Linux distributions are pushing out their new versions. If you are so inclined, you can always pull the patches yourself, tune your compiler options, and make other tweaks today to take greater advantage of these new AMD processors. The upcoming FX-8150 Linux articles have more revealing information.

The poor performance of Buldozer in many popular reviews is a consequence of the bad scheduler in Windows 7, which does not understand CMT.

DDR3 typical latencies 10-15 ns. GDDR5 typical latencies 10-12 ns. Myth: GDDR5 has very poor latencies...

This myth seems to have been initiated by Intel fanboys when Sony presented its AMD-powered console. You can find lots of posters in forums and blogs claiming that "PC is better", that GDDR5 is not used in gaming PCs (aka they did mean Wintel PCs) because drops CPU performance.

Funny, I've seen much higher latencies for GDDR5.

I know the myth is strong.

----------------

Also, just a little historical background, aside from being one of the 2-3 people here who nailed BD's performance prior to release, I'm also the guy who's long held X86 as an arch is simply non-competitive in the low-power (mobile) market, and that Intel's Larabee design (or whatever they are calling it theses days) had no chance of being competitive. I call it the way I see it. And right now, the way I see it, AMD followed the wrong CPU architecture, and that's the way I called it two years ago. Heck, given the move to Trinity/HSA, having lots of cores as the expense of per-core performance makes even LESS sense, given that type of work is best left offloaded to the APU anyways.

The best CPU company right now? Qualcomm. Aside from the fact they are now worth more then Intel, they have the best chance of having constant success in mobile, the one market that is growing at the moment. Sure, they don't have the best performance, but in terms of profit potential, Qualcomm is looking the best right now.

In a perfect world where only technological stuff matters, Bulldozer is a bad architecture. But when one puts Bulldozer in an economic, legal, and managing context, then it looks very much as the only move that AMD could do.

In any case this is the past; upcoming Steamroller is very much Bulldozer made right.

 

[griptwister]

Anyone else notice Newegg raised the prices on some of their Intel and Nvidia products today? The GTX 760s are priced about $50 more than normal, and a few of the z87s are about $20-30 more expensive... I'm just hoping their just trying to generate revenue before AMD releases their better cards.

 

[8350rocks]

Anyone else notice Newegg raised the prices on some of their Intel and Nvidia products today? The GTX 760s are priced about $50 more than normal, and a few of the z87s are about $20-30 more expensive... I'm just hoping their just trying to generate revenue before AMD releases their better cards.

They could be marking them up to mark them back down "on sale" as well...

EDIT: The downward spiral for M$ begins: http://www.tomshardware.com/news/surface-rt-lawsuit-class-action-shareholders-misleading,23875.html
-----------------------------------
AMD market share up 10% Q1 to Q2, Intel up 6%, Nvidia down 5%:
http://www.zdnet.com/pc-shipments-still-dismal-but-q2-gives-amd-and-intel-still-up-and-nvidia-down-analyst-7000019404/

It appears GF is already ramping up 28nm FD-SOI...power consumption drops and performance increases vs. 32nm HKMG PD-SOI.

The interesting part of this graphic, is that it appears they expect to be on track for 20nm FD-SOI in 2014, and 14nm FD-SOI in 2015, though the next shrink looks to be 10nm and it's put out another 1.5-2 years after 14nm.

I think it's good that GF is licensing the ability to use the Silicon process from STMicro in France making all the FD-SOI advancements...

If this holds up, they will perhaps be able to hit the targets for their schedules. Which would mean we could easily see excavator sneak in at the end of next year as a paper launch on 20nm FD-SOI.

Given that Intel will not be shrinking to 14nm FinFET until 2015...AMD may actually gain a process advantage over Intel by that time, as 14nm FD-SOI > 14nm bulk FinFET in terms of both power consumption and performance. Additionally, based on the projections of GF, the 14nm bulk FinFET may actually mean the die is more costly for Intel.

If that's the case, then Intel may be considering retooling their complex process to move to FD-SOI at that point, however, while die costs would shrink some, the costs to change their fab around for SOI would likely offset much of the money they would save in the die costs.

I am curious to see how good Kaveri is, if it's strikingly improved over PD, then the shrink to 20nm may mean AMD could actually be right in the thick of things when excavator launches.

Interesting times to be sure...
-----------------------------------
Here is an interesting read on the SOI Consortium study...the link is to part 3 of the review, but the links to the first 2 parts are at the bottom:

http://www.advancedsubstratenews.com/2012/02/fd-soi-a-look-at-recent-consortium-resultspart-3-of-3-20nm-fd-soi-comes-out-way-ahead/
-----------------------------------
"Hawaii" GPU architecture to be unveiled in Hawaii in Sept:
http://semiaccurate.com/2013/08/07/amd-to-launch-hawaii-in-hawaii/

The most interesting bit in the read is how abysmal Nvidia is actually doing. Their roadmap has literally nothing to compete with AMDs new cards until late next year at the earliest. The even cancelled the Maxwell update that was supposed to come in the Spring.

They are literally floundering like a beached whale.
-----------------------------------
M$, Dell, Blackberry tied together? Maybe...

http://semiaccurate.com/2013/08/12/dell-needs-blackberry-microsoft-needs-dell/

 

[jdwii]

Releasing a new kernel for supporting a new architecture is not the same than releasing fixes to patch the unfixable.

Therefore the unix/linux community had absolutely no problem with AMD, but when Microsoft has serious problems and released buggy hotfixes to fix that bad scheduler, the problem is... AMD.

According to you, the well-known fact that AMD chips work better under linux has nothing to do with Microsoft releasing mediocre products or only caring about Intel (Wintel).

To be fair, its worth noting on of the major contributors to the Linux kernel is: AMD.

What is funny is that Microsoft is one of the top contributors to linux kernel

http://arstechnica.com/business/2012/04/linux-kernel-in-2011-15-million-total-lines-of-code-and-microsoft-is-a-top-contributor/

Also, funny how AMD did about the same in Linux/Windows at release:

http://www.phoronix.com/scan.php?page=article&item=amd_fx8150_bulldozer&num=6

Looses single threaded, competitive with Nahalem multithreaded, typically looses to SB. Same as Windows basically.

But that review was not showing the real Bulldozer performance, unlike what you believe:

Linux users will be able to take full advantage of the Bulldozer architecture sooner than Microsoft Windows customers, which will primarily see the real potential when Windows 8 is released. In the Linux world, there's still some Bulldozer kernel work that's not yet merged and presumably more compiler/kernel optimizations coming, but we will hopefully see all of that merged and ready in time for next spring when Ubuntu 12.04 LTS, Fedora 17, and other Linux distributions are pushing out their new versions. If you are so inclined, you can always pull the patches yourself, tune your compiler options, and make other tweaks today to take greater advantage of these new AMD processors. The upcoming FX-8150 Linux articles have more revealing information.

The poor performance of Buldozer in many popular reviews is a consequence of the bad scheduler in Windows 7, which does not understand CMT.

DDR3 typical latencies 10-15 ns. GDDR5 typical latencies 10-12 ns. Myth: GDDR5 has very poor latencies...

This myth seems to have been initiated by Intel fanboys when Sony presented its AMD-powered console. You can find lots of posters in forums and blogs claiming that "PC is better", that GDDR5 is not used in gaming PCs (aka they did mean Wintel PCs) because drops CPU performance.

Funny, I've seen much higher latencies for GDDR5.

I know the myth is strong.

----------------

Also, just a little historical background, aside from being one of the 2-3 people here who nailed BD's performance prior to release, I'm also the guy who's long held X86 as an arch is simply non-competitive in the low-power (mobile) market, and that Intel's Larabee design (or whatever they are calling it theses days) had no chance of being competitive. I call it the way I see it. And right now, the way I see it, AMD followed the wrong CPU architecture, and that's the way I called it two years ago. Heck, given the move to Trinity/HSA, having lots of cores as the expense of per-core performance makes even LESS sense, given that type of work is best left offloaded to the APU anyways.

The best CPU company right now? Qualcomm. Aside from the fact they are now worth more then Intel, they have the best chance of having constant success in mobile, the one market that is growing at the moment. Sure, they don't have the best performance, but in terms of profit potential, Qualcomm is looking the best right now.

In a perfect world where only technological stuff matters, Bulldozer is a bad architecture. But when one puts Bulldozer in an economic, legal, and managing context, then it looks very much as the only move that AMD could do.

In any case this is the past; upcoming Steamroller is very much Bulldozer made right.

I find this statement to be fallacious, data proves this was a bad choice over cost and performance. Maybe steamroller will finally make Amd some money instead of charging less for more transistors.

 

[jdwii]

8350rocks, that chart basically says Amd can start production on steamroller using 28nm today and we could have them around 3 months or so, i hope Amd doesn't wait for 20nm we know GF will delay that design.

 

[The Q6660 Inside]

Anyone else notice Newegg raised the prices on some of their Intel and Nvidia products today? The GTX 760s are priced about $50 more than normal, and a few of the z87s are about $20-30 more expensive... I'm just hoping their just trying to generate revenue before AMD releases their better cards.

Err, the GTX 760 still seems to be around $260 You may be confusing the 4GBs and 2GBs. The 7900 series has done well, after all, it has been competing for 3 card generations now. History will repeat itself, 9970 to 780 as 7970 is to 580, which the cheaper 7950 defeated.

 

[8350rocks]

8350rocks, that chart basically says Amd can start production on steamroller using 28nm today and we could have them around 3 months or so, i hope Amd doesn't wait for 20nm we know GF will delay that design.

28nm production is ramping up, that's why Kaveri is taking just a tad longer...AMD couldn't resist the power saving features and increased performance...especially considering reduced costs per die.

20nm is going to be excavator. If they keep that on track, we could see excavator as early as Q4 next year.

I expect that once the 28nm FD-SOI process is mature and yields are good enough, we will see the return of the FX series or a rename to Phenom III with a SR product featuring 4/6/8 cores.

AMD likely is not committing to it publicly as they certainly don't want the press to be able to rip them if they cannot deliver on time. Especially considering the positive momentum that they have built as of late.

 

[The Q6660 Inside]

8350rocks, that chart basically says Amd can start production on steamroller using 28nm today and we could have them around 3 months or so, i hope Amd doesn't wait for 20nm we know GF will delay that design.

28nm production is ramping up, that's why Kaveri is taking just a tad longer...AMD couldn't resist the power saving features and increased performance...especially considering reduced costs per die.

20nm is going to be excavator. If they keep that on track, we could see excavator as early as Q4 next year.

I expect that once the 28nm FD-SOI process is mature and yields are good enough, we will see the return of the FX series or a rename to Phenom III with a SR product featuring 4/6/8 cores.

AMD likely is not committing to it publicly as they certainly don't want the press to be able to rip them if they cannot deliver on time. Especially considering the positive momentum that they have built as of late.

Perhaps AMD Phenom FX™ I agree that once the FD-SOI 28nm process matures, we will likely see *Insert Vishera successor's name here* being released.

 

[The Q6660 Inside]

Some news,

Best bundle known to man : http://www.tomshardware.com/news/amd-never-settle-forever-radeon-far-cry-3-deus-ex,23882.html

Intel learned from their IHS issues (Late, but still...): http://www.tomshardware.com/news/Intel-Core-i-74960X,23270.html

 

[8350rocks]

Some news,

Best bundle known to man : http://www.tomshardware.com/news/amd-never-settle-forever-radeon-far-cry-3-deus-ex,23882.html

Intel learned from their IHS issues (Late, but still...): http://www.tomshardware.com/news/Intel-Core-i-74960X,23270.html

Yeah...HD 7990 @ $699 + 3 free games worth $150 = HD 7990 for $549...who wouldn't buy that if they were looking at anything even remotely close...

EDIT: Sapphire Atomic HD 7990 inbound too: http://www.techpowerup.com/187162/sapphire-radeon-hd-7990-atomic-pcb-and-cooling-solution-pictured.html

 

[The Q6660 Inside]

Some news,

Best bundle known to man : http://www.tomshardware.com/news/amd-never-settle-forever-radeon-far-cry-3-deus-ex,23882.html

Intel learned from their IHS issues (Late, but still...): http://www.tomshardware.com/news/Intel-Core-i-74960X,23270.html

Yeah...HD 7990 @ $699 + 3 free games worth $150 = HD 7990 for $549...who wouldn't buy that if they were looking at anything even remotely close...

EDIT: Sapphire Atomic HD 7990 inbound too: http://www.techpowerup.com/187162/sapphire-radeon-hd-7990-atomic-pcb-and-cooling-solution-pictured.html

7990 has\will continue to have 8 free games.

http://www.anandtech.com/show/7218/amd-announces-never-settle-forever-bundle
www.newegg.com/Product/Product.aspx?Item=N82E16814202036

 

[8350rocks]

8!?!?! That's like getting the card for the price of a HD 7950...LOL...WOW!!!

 

[The Q6660 Inside]

8!?!?! That's like getting the card for the price of a HD 7950...LOL...WOW!!!

Now would be the perfect time to upgrade your GPU... What are your specs?

 

[GOM3RPLY3R]

Some news,

Best bundle known to man : http://www.tomshardware.com/news/amd-never-settle-forever-radeon-far-cry-3-deus-ex,23882.html

Intel learned from their IHS issues (Late, but still...): http://www.tomshardware.com/news/Intel-Core-i-74960X,23270.html

Yeah...HD 7990 @ $699 + 3 free games worth $150 = HD 7990 for $549...who wouldn't buy that if they were looking at anything even remotely close...

EDIT: Sapphire Atomic HD 7990 inbound too: http://www.techpowerup.com/187162/sapphire-radeon-hd-7990-atomic-pcb-and-cooling-solution-pictured.html

7990 has\will continue to have 8 free games.

Spoiler

http://www.anandtech.com/show/7218/amd-announces-never-settle-forever-bundle
www.newegg.com/Product/Product.aspx?Item=N82E16814202036

Excuse me as I flip my table:

(╯°□°）╯︵ ┻━┻

*puts it back* ┬──┬◡ﾉ(° -°ﾉ)
.
.
.
*throws Q6660* (╯°Д°）╯︵/(.□ . \)

 

[The Q6660 Inside]

Some news,

Best bundle known to man : http://www.tomshardware.com/news/amd-never-settle-forever-radeon-far-cry-3-deus-ex,23882.html

Intel learned from their IHS issues (Late, but still...): http://www.tomshardware.com/news/Intel-Core-i-74960X,23270.html

Yeah...HD 7990 @ $699 + 3 free games worth $150 = HD 7990 for $549...who wouldn't buy that if they were looking at anything even remotely close...

EDIT: Sapphire Atomic HD 7990 inbound too: http://www.techpowerup.com/187162/sapphire-radeon-hd-7990-atomic-pcb-and-cooling-solution-pictured.html

7990 has\will continue to have 8 free games.

Spoiler

http://www.anandtech.com/show/7218/amd-announces-never-settle-forever-bundle
www.newegg.com/Product/Product.aspx?Item=N82E16814202036

Excuse me as I flip my table:

(╯°□°）╯︵ ┻━┻

*puts it back* ┬──┬◡ﾉ(° -°ﾉ)
.
.
.
*throws Q6660* (╯°Д°）╯︵/(.□ . \)

OW! You mad that you don't have an excuse to go 780 SLI anymore ?