AMD embraces AVX making a new superset with SSE5(256bit support)

Quote:

---

Originally Posted by Chad Boga

Paul DeMone's apt response to Agner

---

pfff Paul DeMone = Shintai^3 :rolleyes:

Quote:

---

Originally Posted by Nedjo

pfff Paul DeMone = Shintai^3 :rolleyes:

---

Angry fanboy getting personal? The anger is intense in this thread. I guess when you cant get the ball you have to go for the person :rolleyes:

Quote:

---

Originally Posted by Shintai

Angry fanboy getting personal? The anger is intense in this thread. I guess when you cant get the ball you have to go for the person :rolleyes:

---

dude why do you find yourself offended by comparison with a guy who's most prominent person in community?

Quote:

---

Originally Posted by Nedjo

pfff Paul DeMone = Shintai^3 :rolleyes:

---

Shintai is pretty knowledgeable, so that sounds about right. :up:

Quote:

---

Originally Posted by Nedjo

absolutely wrong! MS has it's own complier and their compiler +gcc is the most used compliers around, not ICC! That doesn't downplays power of ICC that's extremely efficient complier and extremely optimized for Intel's architecture, and biasedly unoptimized towards AMD's approach to x86 set...

---

Just a shame that code runs faster also on AMD after using the Intel compiler. And if we exclude the basement people and just check companies. the 95% is pretty spot on. And no, MS does not use its own compiler. MS just sells it with VS and use it for any prototype testing. MS dont like subpair performance on its own products. if it can avoid it ;)

Quote:

---

Originally Posted by Shintai

Just a shame that code runs faster also on AMD after using the Intel compiler. And if we exclude the basement people and just check companies. the 95% is pretty spot on. And no, MS does not use its own compiler. MS just sells it with VS and use it for any prototype testing. MS dont like subpair performance on its own products. if it can avoid it ;)

---

I guess there are no reason for so many games and apps/drivers to deploy with VC++ 2005/2008 runtime...

Quote:

---

Originally Posted by Nedjo

absolutely wrong! MS has it's own complier and their compiler +gcc is the most used compliers around, not ICC!

---

Can you support this claim with some statistics data?

Quote:

---

That doesn't downplays power of ICC that's extremely efficient complier and extremely optimized for Intel's architecture, and biasedly unoptimized towards AMD's approach to x86 set...

---

I call BS on the bolded part. ICC is faster than MSC even with AMD CPUs.

Quote:

---

Originally Posted by Nedjo

I guess there are no reason for so many games and apps/drivers to deploy with VC++ 2005/2008 runtime...

---

Are you claiming the runtime DLLs is a MS compiler requirement? Do you know what a compiler even is?

Quote:

---

Originally Posted by Shintai

Do you know what a compiler even is?

---

Dunno about him, but you sure don't :ROTF:

Quote:

---

Originally Posted by STaRGaZeR

Dunno about him, but you sure don't :ROTF:

---

Next you gonna claim that a function API library dependency is the same as a compiler. :ROTF:

You are always ready to make a joke :D

Quote:

---

Originally Posted by informal

EDIT:
I have found the original and revised AVX specs.
Original is here. It was valid until January 2009. Intel released a new specification 4 months ago(roughly) and here is the new pdf covering the revised AVX instr. set specification. I'm not aware if there are more revisions,maybe there are.

---

wow.. just wow, im really baffled. So you claim intel intel just released the next revision of AVX to hamper AMD?

With your own links you have proven, that AVX is far from finished if they already have gone throught 2 (ore more) revisions in less then 1 year, and im sure there are going to be a few more before we finally see it in hardware.

AMD should stop weeping and show some guts again, as they did with AMD64. :yepp:
If amd already has a instruction set ready with FMA, they should release it, cause 2 years is a long time to catch up for intel, might be even eough to pull another AMD64 and intel has to adapet amds solution.

Quote:

---

Originally Posted by Hornet331

snip

---

With sandy bridge due in 2010 the spec for AVX really has to be finished. :welcome:
In any case i dont care if Intel has the right to change the spec. The only thing that i care about is how this affects me as a consumer and the implementations by AMD and Intel being incompatible is only going to slow down adoption of these features in mainstream applications. So :down: for Intel

Quote:

---

Originally Posted by BrowncoatGR

With sandy bridge due in 2010 the spec for AVX really has to be finished. :welcome:

---

The spec changes were related only to FMA which will be introduced in Ivy Bridge.

Quote:

---

In any case i dont care if Intel has the right to change the spec.

---

AMD changed several times it's spec for x86-64 (even right before Intel released it's first P4 supported x86-64). Applause to Intel for not introducing it's own spec for 64 bit. :clap: :D

Quote:

---

Originally Posted by kl0012

The spec changes were related only to FMA which will be introduced in Ivy Bridge.

AMD changed several times it's spec for x86-64 (even right before Intel released it's first P4 supported x86-64). Applause to Intel for not introducing it's own spec for 64 bit. :clap: :D

---

Yep! There were several threads about Intel stealing from AMD and a corrected glitch of was proof:up:

But Intel did introduce their own 64bit, it just wasn't a Hybrid X86-64.

Links of interest:
http://forums.amd.com/devblog/
http://blogs.amd.com/nigeldessau/200...-than-fiction/

Quote:

---

Originally Posted by N.Dessau

There is a commonly held fallacy that there is one single x86 instruction set. In reality, while all x86 chips run about 99% similar instructions, no two suppliers run exactly the same base. We have a different set to Intel, which is a different set to Via and so on. In fact, one of the things that differentiates our server line from Intel’s is that they don’t even have the same set of functions across the Nehalem line - where as we run all the same functions on the entire family of Quad-Core AMD OpteronTM processors.

This is one of the reasons why AMD Opteron processor-based servers make such good disaster recover solutions - you really can failover running virtual machines to newer, smaller standby systems without worrying that some of the processor functions may not be supported.

While the AMD Opteron processor retains backward compatibility, it is fair to point out that as we deliver new function at each generation, we often have to add extensions to the x86 instruction set (examples are virtualization and 64-bit extensions).

Changing the instruction set can be both complex and expensive for application developers and painful for system designers. AMD recognizes this, and we are trying to reduce some of this cost and complexity by helping to unify the x86 instruction set with the adoption of the Advanced Vector Extensions (AVX).

AMD has always been a champion of open and industry standards, and by adopting the AVX instructions for x86 processors initially announced by Intel in 2008, we can help move this ideal forward. We believe that by proposing and embracing enhancements to the instruction set, AMD provides software developers with a great step towards a more standard platform for innovation.

Now, originally we had focused on what we had called SSE5, a specification we proposed for review by the industry in 2007. However, due to the overlap of functionality between the AVX instructions and SSE5, AMD has decided to recast the SSE5 instructions into the AVX framework. AMD made decision to ensure the continued compatibility of x86 software, and plans to incorporate AVX instructions into AMD processors in 2011.

And, still, we want to continue to advance the ball. In addition to embracing the AVX specification, AMD is proposing further enhancement to the current version of this specification called eXtended Operations (XOP). Given there are features of the SSE5 specification that were positively reviewed in the news and not in the current version of AVX, we have incorporated them into the new proposal. Examples of the functionality include:

* Supporting Enhanced Vectorization
* Accelerating traditional DSP Multi-Media algorithms
* Accelerating floating point algorithms for High Performance Computing



If you want to review the AVX or XOP, AMD is posting theses specification here. I also encourage you to go read a blog written by Dave Christie, a Fellow in our Design Engineering team, to get more insight into the technical details and read what some of our technology partners have to say about this change.



You know, when I hear people cry, “Do not fork the x86 instruction set!” what I really hear is people saying, “Give up driving instruction set innovations!”

Well, there are two reasons why this won’t happen:

* Innovation ‘R US. We believe that bringing innovation to the market is one of our key values and we plan to continue to do what we can to bring users systems that better serve their needs
* There really isn’t a single static x86 instruction set and we need as an industry to make evolution of this instruction set. That’s why we publish changes we are proposing for discussion (and haven’t done it in secret). Our users and the application developers may have good ideas too.

The x86 instruction set will continue to evolve and change and wouldn’t it be great if we could do it together?

Nigel Dessau is senior vice president and chief marketing officer at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such links sites and no endorsement is implied.

---

Quote:

---

Originally Posted by Dave Christie,senior architect

Since we don't control the definition of AVX, all we can say for sure is that we expect our initial products to be compatible with version 5 of the specification (the most recent one, as of this writing, published in January of 2009), except for the FMA instructions, which we expect will be compatible with version 3 (published in August of 2008).

Why the FMA difference? This was not something we did lightly. In December of 2008, Intel made significant changes to the FMA definition, which we found we could not accommodate without unacceptable risk to our product schedules. Yet we did not want to deprive customers of the significant performance benefits of FMA. So we decided to stick with the earlier definition, renaming it FMA4 (for four-operand FMA - Intel's newer definition uses what we believe to be a less capable three-operand, destructive-destination format). 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.

---

*cough* marketing tool *cough*

AMD to support Intel's AVX instruction set
http://techreport.com/discussions.x/16871

Well this blog post from Mr. Dave Christie is really shedding more light into the whole SSE5/AVX confusion.

A few key points we can get from reading his post(and these do make my topic title vaild,ie. it IS a SUPERSET since AMD will support BOTH AVX and their own XOP extensions!):

1) AMD will support AVX instr. set extension while adding its OWN extension set named XOP.CVT16 and FMA4.

Quote from Mr. Christie's post :

Quote:

---

This week, AMD is making a couple of very important announcements for developers: support of Intel's Advanced Vector Extensions (AVX) instruction set in future AMD processors, and the adaptation to the AVX framework of AMD's previous SSE5 instruction set proposal. The latter step has resulted in three new extensions: XOP (for eXtended Operations), CVT16 (half-precision floating point converts), and FMA4 (four-operand Fused Multiply/Add). In this posting I'll give an overview of the capabilities that these extensions provide, and also some insight into why we're taking this step.

---

Quote:

---

With this duplication of functionality between SSE5 and AVX/FMA, and AVX's additional features, [B]we felt the right thing to do was to support AVX.[/B] In our minds, a more unified instruction set is clearly what's best for developers and the x86 software industry. With our acceptance of AVX, a key aspect of this instruction set unification is the stability of the specification. Since we don't control the definition of AVX, all we can say for sure is that we expect our initial products to be compatible with version 5 of the specification (the most recent one, as of this writing, published in January of 2009), except for the FMA instructions, which we expect will be compatible with version 3 (published in August of 2008).

---

FMA differences:

Quote:

---

Why the FMA difference? This was not something we did lightly. In December of 2008, Intel made significant changes to the FMA definition, which we found we could not accommodate without unacceptable risk to our product schedules. Yet we did not want to deprive customers of the significant performance benefits of FMA. So we decided to stick with the earlier definition, renaming it FMA4 (for four-operand FMA - Intel's newer definition uses what we believe to be a less capable three-operand, destructive-destination format). 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.

---

Additional value through added previous SSE5 instructions into the AVX spec. thus giving BD cores some more functionality:

Quote:

---

The fact remains that AVX does not incorporate all of SSE5's features. Since SSE5 was based on months of discussions with ISVs on what sort of capabilities they felt were needed, and had been positively reviewed by the industry when we first put out the specification, we decided to follow through with development of these additional features. To do so most effectively, we redefined them in the AVX framework, resulting in the XOP extension.

---

2) as a natural consequence of 1)-full AVX support ,AMD must support 256bit wide SSE2/3/4.. instruction set extensions too. This means BD cores will have a superset of full AVX inst. set extensions PLUS an AVX-adopted (previous SSE5) XOP,CVT16 and FMA4 extension sets!

This is very important bit of news. The blog post by senior architect tells us that AMD is embracing the AVX spec. AND incorporating their new SSE5 additional instructions into the AVX-like decoding scheme.The only difference is the FMA extensions which Sandy Bridge will lack anyway and BD cores can't change since it would significantly alter the time to market of AMD's future new gen. uarchitecture.


So Superset stays and was 100% on the money :rofl::ROTF:



EDIT:

A few comments from AMD's industry partners that emphasize the importance of AVX support and of a new superset that AMD created:

Quote:

---

Absoft
"The addition of AVX support by AMD is a great move as it enables superior performance potential across AMD's x86 family of processors," said Wood Lotz, Absoft CEO. "AMD's use of AVX can also simplify development of high performance compilers and tools for companies like Absoft, and enable customers across a wide variety of industries to build faster applications."

Acumem
"Acumem fully supports AMD's adoption and enhancement of the AVX instructions and will follow this standard as it becomes available in the market. As an ISV for performance tools we clearly see potential for performance improvements with these new additions" said Mats Nilsson, VP Software Engineering at Acumem.

Axceleon
"Axceleon applauds AMDs efforts to support both specifications, AVX and SSE5, in their XOP specification proposal. The further enhancements in FMA4 which accelerate floating point algorithms are very important to Axceleon's HPC customers and will be welcomed across the board" said Mike Duffy, CEO of Axceleon.

Bibble Labs
"We at Bibble Labs are constantly looking for performance improvements, and as such we are investigating AVX because of the possible performance advantage it might bring. We also appreciate that AMD is taking an active role to ensure the instruction sets converge and not create separate, conflicting instruction sets," said Jeff Stephens, Vice President of Product Development, Bibble Labs.

Cakewalk
"We commend AMD for taking an active role in open standards, by unifying the x86 instruction set and merging SSE5 into the AVX specification. This can help improve compatibility and simplify the work for developers implementing this. We look forward to investigating AVX for potential advantages it may bring to our real-time applications and plug-ins," said Noel Borthwick, Chief Technology Officer, Cakewalk.

Nero
"We are pleased that AMD has decided to adopt the AVX instruction set extension instead of offering a variant," said Simone Hoefer, General Manager, Technology at Nero AG. "This will help reduce implementation complexity and multiple code-paths. We are confident that the SIMD (SSE/SSE2) optimizations already implemented will scale nicely to 256-bit/AVX, allowing us to truly embrace this new development."

Smith Micro Software
"Having to choose acceleration solutions that work well on both AMD and Intel CPU platforms, Smith Micro welcomes convergence of the x86 instruction set. AMD supporting AVX is desirable from Smith Micro's point of view," said Uli Klumpp, director of engineering, Smith Micro Software, Inc. "The AVX instruction set extensions are looking promising for further optimizing our computationally most demanding software, DCC and data compression products such as Poser and StuffIt."

Sonic Solutions
"AMD's adoption of AVX will help Sonic unify some of its engineering efforts and reduce development costs," said Jim Roth, Chief Technical Officer, Sonic Solutions. "We welcome this initiative and the proposed enhancements to the x86 processor architecture, which we will leverage to increase the responsiveness and performance of our digital media applications."

---

Wasn't AMD going to create a new extension to X86 with purpose of the Fusion?
Like new instructions that run on GPU.

So Shintai what's your comment on this new development? :p: What happened with your "superset busting"?:shrug:

Quote:

---

Originally Posted by informal

So Shintai what's your comment on this new development? :p: What happened with your "superset busting"?:shrug:

---

Quote:

---

Originally Posted by Shintai

*cough* marketing tool *cough*

---

there you go :)

Never mind his comment has not addressed the issue at all ... And issue being AVX + SSE5(changed sse5) support in BD cores in 2 years.

LOL, UBER PWNAGE. Thanks to AMD for the big clarification.


I already mentioned prior that SSE5 was a superset in general due to its implementation of FMA, but several specs did not adhere. Now add AMD being fully compliant with AVX to the previous setting, it still has FMA inside the CPU spec itself.

So AMD beats Intel to releasing their first SSE5AVX CPU? Whoa.

Quote:

---

Originally Posted by Shintai

*cough* marketing tool *cough*

---

What an apt description of... you? :ROTF:

We can coin a new expression on the XS,a small joke if you like : "pulling a sh... on someone" :D -meaning you ignore the facts and stay out of the threads in which you ended up wrong and hoping the thread dies and your pwng is forgotten :D :p:

Quote:

---

Originally Posted by Hornet331

How is that and amd thread when the titel mentions both?... oh well, seems I forgot the amd fanboy rule #1: AMD in the title means amd exclusiv, even mentioning the name intel is thread crapping...

When you call for mods, how about changing the thread title itself, it's an invitation for flaming... informal could easily have chosen another thread title, but it wouldn't have caused that much of a stir up... :rolleyes: (talk about double standards)

---

You know I get a little sick of this Bull :banana::banana::banana::banana: childish name calling and labeling that you troublemakers are oh so fond of! I see all of you with the Balls to call everybody else Fan Boys because it does not coincide with you line of think or your preference ....well tough :banana::banana::banana::banana:!

The fact all of you that are continuously spouting AMD Fan Boy .. AMD Fan Boy only goes to prove one thing that its Intel or the Highway and we are just commoners and beneath all of you because we prefer AMD ......Get Real and Grow Up :rolleyes: How is that you are not a Fan Boy and all of the other chumps that come into these AMD Threads and Purposely Derail them?:rolleyes:.....Once again...OK:rofl:


Speaking of Intel who do you have to thank for your Insight into Overclocking a CPU with a IMC ??? You guessed it the AMD Fan Boys that you all kick ond torment relentlessly ...You guys make me laugh! Self Proclaimed experts talking a Bunch of :banana::banana::banana::banana: is all you do when we were the Ones Debugging Overclocking Quad Core with IMC you were all Talking :banana::banana::banana::banana: and Making Fun of us ..... I guarantee you that for you die Hard Intel Fans here you would know nothing about not blowing up your Precious Nehalem Rigs if it wasn't for us doing all of the work for the Past Year and a Half ya'll wouldn't have a clue in hell and there sure as hell would have been allot of Toasted CPU'S and Motherboards if it weren't for all of us lowly Commoners in the AMD Sector.

Do me a favor all of you shut up and be thankful for what we have given you we are all tired of hearing your Whiny Frigging Negative dysfunctional Rhetoric so piss off or be civil and have some damn manners and respect towards your fellow man.