Haswell will rival graphics performance of today's discrete cards!

[ieatdonuts]

Gamers are a MINORITY in the land of PC's...*sigh*

Wishfull thinking makes lousy arguments...

Yes. I like my PC games, but this is the truth.

 

[Nemesis 1]

Why compromise?

The AVX2 instruction set brings major GPU features to the CPU cores. Haswell will still have an IGP, but it might be assisted by the massive computing power of these AVX2 enabled cores. Beyond that, CPUs may very well become homogeneous, i.e. performing graphics processing on fully unified cores. It would also be a superior architecture for generic high-throughput computing.

Everthing your saying is in fact true . But these guys don't want to talk about the Topic . They want to talk about . Intel Drivers and LLano and how Intels graphics on IGP don't measure up . The AMD guys don't want to talk about AVX II or for that matter The Vexprefix . They haven't a clue . What the Vex prefix is or what it does. Even if they did they would avoid the subject. Than you would get AMD has AVX also . LOL ya they sure do but they don't have mitosis. Which is exactly what the Vexprefix is . Code inside of code. The AVX ii announment and what intel is doing with Vexprefix IN all present X86 apps.. This is what there avoiding...AVX2 - Integer data types expanded to 256-bit SIMD

 

[Riek]

Everthing your saying is in fact true . But these guys don't want to talk about the Topic . They want to talk about . Intel Drivers and LLano and how Intels graphics on IGP don't measure up . The AMD guys don't want to talk about AVX II or for that matter The Vexprefix . They haven't a clue . What the Vex prefix is or what it does. Even if they did they would avoid the subject. Than you would get AMD has AVX also . LOL ya they sure do but they don't have mitosis. Which is exactly what the Vexprefix is . Code inside of code. The AVX ii announment and what intel is doing with Vexprefix IN all present X86 apps.. This is what there avoiding...AVX2 - Integer data types expanded to 256-bit SIMD

I shall quote someone from this thread..

lol ? so much cluelessness in this post. Resurrect the thread in the cpu forum where you where proven wrong about this, if you want to discuss it again, since it's ot here.

Please open up that thread for that propaganda. Most people would love to talk about it... most people did talk about it... and everybody agreed you were wrong.


I don't think Haswell would have any problems delivering gpu performance and quality equally to today low end discrete gpu's. Given that those low end gpu's are delivering about 4-5x the flops of HD3000. This should be doable. (given a die shrink and more transistors). Heck i even expect that to be done in IB..

AVX2 will be great, given that the software support will come in around 2014 it will be great to compare it the next gen gen BD with a next gen GNC of AMD.

 

[Cerb]

Why compromise?

The AVX2 instruction set brings major GPU features to the CPU cores. Haswell will still have an IGP, but it might be assisted by the massive computing power of these AVX2 enabled cores. Beyond that, CPUs may very well become homogeneous, i.e. performing graphics processing on fully unified cores. It would also be a superior architecture for generic high-throughput computing.

Of this I don't think there should be any doubt. AMD has higher-powered parallel compute ability now, and should with GCN-based graphics, but that will gradually coalesce, as well, and programming standards that aren't graphics based (AMP, FI) are going to be as kind to Intel as anyone else.

The trick is reconciling the ease of many data streams (GPU threads, with non-unique program counters) with the CPU's byte-shuffling. A homogeneous software/memory environment, with heterogeneous ISAs, would work perfectly well, but if Intel goes in another direction, even if just for sake of kicking AMD (who, IMO, have missed some major opportunities in the last few years), what's the market going to do? Follow AMD is an unlikely answer.

For HPC, extensions such as AVX(n+1) are the way to go (AVX/AVX2 seems awfully complicated for what it does, compared to XOP, but Intel likes doing that), but time will tell if they are as good as, or superior to, integrated non-x86 coprocessors for the job, when it comes to perf/watt in commodity devices, with commodity software. I personally like the coprocessor idea better, as a programmer, but not enough that I would gladly wildly different loops for each hardware platform.

 

[ieatdonuts]

I'm pretty sure the point everyone is trying to make, Nemesis1, is that

a) Intel has made a lot of claims and few results in graphics. We'll believe it when we see it.

b) AMD isn't going to sit around and wait. Chances are they'll have a fusion processor that works as good if not better.

I like the idea of a homogeneous CPU/GPU, I hope Intel comes up with something gold.

 

[Nemesis 1]

I shall quote someone from this thread..



Please open up that thread for that propaganda. Most people would love to talk about it... most people did talk about it... and everybody agreed you were wrong.


I don't think Haswell would have any problems delivering gpu performance and quality equally to today low end discrete gpu's. Given that those low end gpu's are delivering about 4-5x the flops of HD3000. This should be doable. (given a die shrink and more transistors). Heck i even expect that to be done in IB..

AVX2 will be great, given that the software support will come in around 2014 it will be great to compare it the next gen gen BD with a next gen GNC of AMD.

Actually I proved the AMD mouth peace 100% wrong . I won that debate hands down by presenting the real facts from the documents . AMD marketing mouthpeace kept saying this or that but when it came time to show . The AMD documents didn't contain the required information . The thread is here . You Say everyone else was right and I was wrong . Than later info came out on AVXii which confirmed what I was saying to be all facts.
You show me in amds documents which are in that topic that AMD has anything like the Vex prefix . AMD doesn'r not have the Vexprefix nor will they ever have it . Topics here show me were AMD has VEX prefix . When this occurs doesn't matter . BD hype started WHEN?

read Cerb above . He is getting it pretty good . Now it wait and see.

 

[Nemesis 1]

I'm pretty sure the point everyone is trying to make, Nemesis1, is that

a) Intel has made a lot of claims and few results in graphics. We'll believe it when we see it.

b) AMD isn't going to sit around and wait. Chances are they'll have a fusion processor that works as good if not better.

I like the idea of a homogeneous CPU/GPU, I hope Intel comes up with something gold.

AMD recently announced what their plans were and AVX wasn't in them . As they were cluesless about the qualities of the VEX prefix . In the thread or topic mentioned above I presented all the facts and there was no counter points that were confirmed . AMDS mitosis is a BD core . LOL

If amd is going to match intel they really need a compiler . As the AMD mouth piece said . AMD will not be using intels compilers. The compilers intel is using gets its beginning in russia . Elbrus which intel bought in 2004. Intel already had good compilers but now they have great compilers . This is in fact a compiler game.

 

[CPUarchitect]

Of this I don't think there should be any doubt. AMD has higher-powered parallel compute ability now, and should with GCN-based graphics, but that will gradually coalesce, as well, and programming standards that aren't graphics based (AMP, FI) are going to be as kind to Intel as anyone else.

Indeed, but also note that AMD only has higher theoretical compute ability. Running GPGPU applications on any GPU gives you only a fraction in effective performance, which really isn't a lot when that GPU is an IGP. There are numerous practical bottlenecks which prevent contemporary GPU architectures from reaching high performance at anything different from legacy graphics workloads.

Don't get me wrong, Llano has a pretty fast IGP, but it's really of no use for anything other than games. We still need fast CPU cores for everything else. GCN may attempt to change that, but it won't come for free! The increased dynamic scheduling capabilities, the unified address space, the larger register files to keep more scalar SIMD instructions in flight for longer, etc. all cost additional transistors. So the relative computing density will go down.

Heterogeneous computing looks like a dead end to me. Eventually it will be almost like having an x86 and a PowerPC processor on one chip, instead of just twice the number of cores of one type, which is clearly much easier to develop for and allows for flexible workload balancing.

The trick is reconciling the ease of many data streams (GPU threads, with non-unique program counters) with the CPU's byte-shuffling.

I don't think there's anything to reconcile. The GPU architecture demands keeping lots of threads in flight to achieve high throughput. That's really a burden, because you need to share the available on-die storage between all these threads, which in turn causes more cache misses and thus creates bottlenecks.

The CPU requires much fewer threads, thanks to out-of-order execution. It's obviously a more expensive form of dynamic scheduling, especially in terms of power consumption, but that might be solved by executing 1024-bit AVX instructions on 256-bit units in four cycles, and clock gating the idle logic thanks to the lower instruction rate (without lowering the throughput).

A homogeneous software/memory environment, with heterogeneous ISAs, would work perfectly well...

I don't think it would. The problem is that many workloads consist of a mix of sequential and parallel code. It's a complex tasks to require developers to split their code into disjunct pieces, and still achieve good performance. The communication overhead between heterogeneous cores puts a serious damper on effective performance. Having the ability to do both sequential and parallel processing within the same core, even from one instruction to the next, is a significant advantage both from a programming ease point of view, and a performance point of view.

 

[ieatdonuts]

If amd is going to match intel they really need a compiler . As the AMD mouth piece said . AMD will not be using intels compilers. The compilers intel is using gets its beginning in russia . Elbrus which intel bought in 2004. Intel already had good compilers but now they have great compilers . This is in fact a compiler game.

Don't they have the Open64 compiler?

http://developer.amd.com/tools/open64/Pages/default.aspx

 

[CPUarchitect]

You show me in amds documents which are in that topic that AMD has anything like the Vex prefix . AMD doesn'r not have the Vexprefix nor will they ever have it .

Bulldozer is confirmed to support all of AVX, which demands support for the VEX2 and VEX3 prefixes, and on top of that will have XOP and FMA4 extensions.

 

[Nemesis 1]

Bulldozer is confirmed to support all of AVX, which demands support for the VEX2 and VEX3 prefixes, and on top of that will have XOP and FMA4 extensions.

Nice link give me time to read it and research . As it is right now Intel vex prefix can work with Intel compilers and the code path. I really don't believe AMD was given that code by intel . After the years intel spent developing it .

 

[Nemesis 1]

OK I read it . Could you please copy and paste the part that confirms that AMD has a compiler that will use the vexprefix and its underlying code . I missed it or I am not comprehinding it . AMD has to say there prefix has 3 digit code that calls on the code in intels compiler replace long code to simple 3 digit code

 

[Outrage]

Actually I proved the AMD mouth peace 100% wrong . I won that debate hands down by presenting the real facts from the documents . AMD marketing mouthpeace kept saying this or that but when it came time to show . The AMD documents didn't contain the required information.

It takes about 10 seconds to skim through this document page 1-5 to see that you are wrong in so many ways it's not even funny.

http://support.amd.com/us/Processor_TechDocs/26568.pdf (page 41->)

And here is the thread where n1 is walking his path to epic failure.

http://forums.anandtech.com/showthread.php?t=2168871

 

[Nemesis 1]

I have not seen 1 thing that says AMD has the Vex 3 digit code that replaces longer code. Its not just the prefix . as the compiler contains that longer code and not the prefix itself . The 3 digits only tells the compiler what to do in the instruction set.

I am sorry I have not seen this proof . Show me were in AMDs AVX document that AMDS prefix does this . You can't because they cant .You best do more than skim . look at cupid

 

[Nemesis 1]

It takes about 10 seconds to skim through this document page 1-5 to see that you are wrong in so many ways it's not even funny.

http://support.amd.com/us/Processor_TechDocs/26568.pdf (page 41->)

And here is the thread where n1 is walking his path to epic failure.

http://forums.anandtech.com/showthread.php?t=2168871

Page 41 says nothing about the prefix containing code that replaces the longer code . AMD said they are using GNC compiler . So without intels compiler AMD and the compiler has to develop all this code . They can't not use intels. They have their own which can do the same . When its developed, But its not the same as intels Vex prefix . Don't hold your breath waiting .

 

[Outrage]

Hahahaha, this is pointless and off topic.

 

[Jionix]

If at first you don't succeed, confuse them.

 

[waffleironhead]

Everthing your saying is in fact true . But these guys don't want to talk about the Topic . They want to talk about . Intel Drivers and LLano and how Intels graphics on IGP don't measure up . The AMD guys don't want to talk about AVX II or for that matter The Vexprefix . They haven't a clue . What the Vex prefix is or what it does. Even if they did they would avoid the subject. Than you would get AMD has AVX also . LOL ya they sure do but they don't have mitosis. Which is exactly what the Vexprefix is . Code inside of code. The AVX ii announment and what intel is doing with Vexprefix IN all present X86 apps.. This is what there avoiding...AVX2 - Integer data types expanded to 256-bit SIMD

If we havnt a clue as you say. How about you start a thread in cpu that covers AVX?

 

[Nemesis 1]

Hahahaha, this is pointless and off topic.

Off topic . Man you best check the Title . Llano was off topic Intels drivers were off topic .

 

[Nemesis 1]

If we havnt a clue as you say. How about you start a thread in cpu that covers AVX?

Its simple enough . This is a haswell topic . Its simple to prove me wrong . Ya can't use an Article . In AMDs AVX documents Show were a simple 3 digit code replaces the longer code . Using an intel compiler. When ya do this I lose the debate, Cupid is my friend.

 

[Outrage]

If we havnt a clue as you say. How about you start a thread in cpu that covers AVX?

Deep inside i think he know that he lost that one, he should probably head over to software and talk about compilers instead.

 

[waffleironhead]

Its simple enough . This is a haswell topic . Its simple to prove me wrong . Ya can't use an Article . In AMDs AVX documents Show were a simple 3 digit code replaces the longer code . Using an intel compiler. When ya do this I lose the debate, Cupid is my friend.

I'm not trying to prove you wrong, you just seem to insert this AVX, prefix of vex, et all into quite a few threads. Wouldn't you agree that one concise thread covering the issue would benefit us all? Care to share your knowledge of the issue with the forum?

 

[Outrage]

Its simple enough . This is a haswell topic . Its simple to prove me wrong . Ya can't use an Article . In AMDs AVX documents Show were a simple 3 digit code replaces the longer code . Using an intel compiler. When ya do this I lose the debate, Cupid is my friend.

So if an intel compiler compiles like crap on an amd cpu you won the argument, hahahahaha

thats a long walk from amd don't support vex prefix to intel compilers dont compile as good on amd vs intel.

 

[grimpr]

If amd is going to match intel they really need a compiler.

There ya go.

http://llvm.org/
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine
http://blogs.amd.com/developer/2011...=feed&utm_campaign=Feed:+amd/all+(All+of+AMD)
http://www.appleinsider.com/articles/08/06/20/apples_other_open_secret_the_llvm_complier.html&page=2

 

[Nemesis 1]

Sorry I had to take care of grandchildren . This is from CPUarch . link.

It will have a different CPUID feature flag from Intel’s FMA extension. At some future point, we will likely adopt Intel’s newer FMA definition as well, coexisting with FMA4. But as you might imagine, we may wait until we’re sure the specification is stable.

Ya they will be waiting till hell freezes over.