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

[Chad Boga]

Professor Fog is much more into instruction set analysis than Paul ever was or will be.

It is not about analysing instruction sets, it is the ludicrous belief that Intel is honour bound to help out AMD and when they don't(surprise surprise), the irrational come out to criticise them.

In the end MS will probably have a say in this matter too.Will be interesting to see how this one turns out.

If they are now both on the same page, what is there to see?

If they are different, then it most likely would be a rerun of SSE vs 3DNow.

[informal]

Why did you skip the crucial part of the post:

The fact is the very second AMD made adjustments to SSE5 and made it compatible to AVX back in January,intel changed the spec again and made it incompatible again. This is imo a clear sign of weakness on intel's part since they know that initial avx with no FMA instruction in 1st iteration of SB will be no match for new avx-like AMD instruction set in BD cores in 2011.SO they made it incompatible again by changing the spec on the fly after AMD posted their revised specification

AMD did follow intel and changed the way decoding was done in the revised spec and (surprise surprise ) intel changes their avx specification again...Mr Fog just wants the mess with instruction set extensions to be over and a standardization body to be formed.

As for MS,Hans posted that he hopes AMD is just a first to post a MS "inspired" AVX/SSE5 common instr. set extension.

[Chad Boga]

Why did you skip the crucial part of the post:

Because it wasn't crucial and was irrelevant to rational thought.

AMD did follow intel and changed the way decoding was done in the revised spec and (surprise surprise ) intel changes their avx specification again...Mr Fog just wants the mess with instruction set extensions to be over and a standardization body to be formed.

Well Mr.Fog is just going to have to accept that Intel has the right to improve their product line and that they are not under an obligation to give a helping hand to their rival.

You should accept that too.

As for MS,Hans posted that he hopes AMD is just a first to post a MS "inspired" AVX/SSE5 common instr. set extension.

I hope he is right, I just doubt that he is.

[Shintai]

MS got nothing to say with AVX. And the reason is 95% of all companies, including Microsoft uses Intel compilers.

[Vozer]

Thou shalt NOT talk about Intel.

[informal]

Because it wasn't crucial and was irrelevant to rational thought.

Lol "wasn't crucial and was irrelevant to rational thought"? What kind of an answer is that??

Maybe irrelevant to you or intel fans,but to anyone objective enough it's clear what intel did and it's lame .They can keep revising the spec anytime AMD matches or exceeds them in engineering with much less resources,but hey it's the world we live in

[ajaidev]

MS got nothing to say with AVX. And the reason is 95% of all companies, including Microsoft uses Intel compilers.

Not true at least the MS part. MS use both intel and amd for 32bit and only amd for 64bit. This was after AMD sued INTEL back in 05. The compilers are checked and bisected by both Intel and Amd to make sure that everything is in order.

http://www.betanews.com/article/Suit...AMD/1121274628

http://techreport.com/discussions.x/8547

[STaRGaZeR]

Shintai is a true guru of compilers, 32/64-bit and similar

Not.

[hurleybird]

Well Mr.Fog is just going to have to accept that Intel has the right to improve their product line and that they are not under an obligation to give a helping hand to their rival.

Your comparison is beyond idiotic. How does changing their coding scheme for the sole purpose of keeping it incompatible with AMD's "improve their product line"? How is it that you think the mere act of not doing something hurtful (both to AMD and the market in general) is akin to "giving a helping hand". And you're the one criticizing other's posts of being "irrelevant to rational thought"? I'm sorry for advancing the "argument", but this poor thought and blatant fanboyism really needs to get called out.

[Zucker2k]

Your comparison is beyond idiotic. How does changing their coding scheme for the sole purpose of keeping it incompatible with AMD's "improve their product line"? How is it that you think the mere act of not doing something hurtful (both to AMD and the market in general) is akin to "giving a helping hand". And you're the one criticizing other's posts of being "irrelevant to rational thought"? I'm sorry for advancing the "argument", but this poor thought and blatant fanboyism really needs to get called out.

I want to see a screenie or it didn't happen. In other words, where's the evidence? I see a lot of people linking to nothing but speculation. Maybe this forum needs a rule that links should also reference facts; that should help with toning down the hostility in here. Too much bs and not enough facts. Unfortunately, the thread itself is based on same - speculation.

[informal]

I want to see a screenie or it didn't happen. In other words, where's the evidence? I see a lot of people linking to nothing but speculation. Maybe this forum needs a rule that links should also reference facts; that should help with toning down the hostility in here. Too much bs and not enough facts. Unfortunately, the thread itself is based on same - speculation.

Prof. Agner Fog made a topic at ace's hw which is still active.AMD embraced intel's AVX decoding scheme (at least the one that was valid back in Jan.) and intel recently changed it, again,thus making AMD's now revised SSE5-AVX incompatible- again

Quote:

The blame here is really on Intel. They have changed their specifications for FMA instructions without informing AMD in time. They must have known that AMD had plans about changing their coding scheme to make it compatible with Intel's because there have been patent-clearing negotiations between the two companies about this issue.

It seems that AMD are the nice guys in this case. They have made great sacrifices by dropping their SSE5/DREX coding scheme and replacing it with Intel's scheme for the sake of compatibility. And then Intel have blown it all by changing their specs once again. Arghhhhh!!!!!!

[Zucker2k]

Prof. Agner Fog made a topic at ace's hw which is still active.AMD embraced intel's AVX decoding scheme (at least the one that was valid back in Jan.) and intel recently changed it, again,thus making AMD's now revised SSE5-AVX incompatible- again

Quote:

Ok, let's see:

Originally Posted by Mr. Agner Fog
The blame here is really on Intel. They have changed their specifications for FMA instructions without informing AMD in time. They must have known that AMD had plans about changing their coding scheme to make it compatible with Intel's because there have been patent-clearing negotiations between the two companies about this issue.

It seems that AMD are the nice guys in this case. They have made great sacrifices by dropping their SSE5/DREX coding scheme and replacing it with Intel's scheme for the sake of compatibility. And then Intel have blown it all by changing their specs once again. Arghhhhh!!!!!!I haven't even bothered to read the link but those patches of it posted are enough. The last bolded word is indicative of a tortured reaction from a partisan, and not an objective presentation of a formal scholarly paper. The speculative language alone makes that point moot.

[informal]

Mr. Fog is a well respected member of the community and I may say he is a man that respects intel tremendously.I guess you said he was "a partisan who had a tortured reaction" is because you don't know much (if anything) about him... The fact you are not aware what he did for software community with his great optimization guides ,especially for intel hardware, makes your post a bit less harsh. Next time inform better before talking crap about other people.

[Chad Boga]

Your comparison is beyond idiotic.

I would say that description better fits your understanding of the issues at hand here.

How does changing their coding scheme for the sole purpose of keeping it incompatible with AMD's "improve their product line"? How is it that you think the mere act of not doing something hurtful (both to AMD and the market in general) is akin to "giving a helping hand". And you're the one criticizing other's posts of being "irrelevant to rational thought"? I'm sorry for advancing the "argument", but this poor thought and blatant fanboyism really needs to get called out.

Where is your evidence that Intel only made changes to create incompatibility with and for AMD?

Where is your evidence that the changes Intel made didn't improve the utility of the instructions they are seeking to implement?

Unless you can prove either, the rational default assumption is that Intel made the changes to make their instruction set better.

[Chad Boga]

Lol "wasn't crucial and was irrelevant to rational thought"? What kind of an answer is that??

Maybe irrelevant to you or intel fans,but to anyone objective enough it's clear what intel did and it's lame .They can keep revising the spec anytime AMD matches or exceeds them in engineering with much less resources,but hey it's the world we live in

So despite you having no proof that Intel made the changes just to stuff up AMD, you will pursue that line of "thought" anyway.

Despite having no evidence that the changes that Intel made to their extension are not an improvement to them, you will still spread the "Intel is Satan" FUD.

As Paul DeMone alluded to, entitlement mentality gone mad.

[hurleybird]

Unless you can prove either, the rational default assumption is that Intel made the changes to make their instruction set better.

Really? And why would the rational default assumption be to side with Intel? Claiming your opinions are rational without describing your reasoning doesn't make you rational -- quite the opposite in fact. Given the fact that Intel has done this sort of thing before, where their compilers would disable SSE instructions in non-Intel processors regardless of ability (prior history), and that Intel will be lacking FMA instructions in the original AVX implementation (motive), and the timing of the entire fiasco, I don't see why the "default rational assumption" should be that everything is one giant coincidence.

[informal]

Chad ,Mr Fog writes optimization manuals for intel hardware,I think he knows "a bit better" how things stand in AVX land than you do . Not only him,but several Ace's members stated the new specification was released just in time to beat AMD's release of their new instruction set extension . And AMD did change their drex decoding scheme just to embrace the previous VEX decoding that was the basis of previous AVX revision.

It amazes me how far will you go in intel's defense. Are you their lawyer, spokesperson or what?

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.

Also note that intel has stated that they won't have FMA(the crucial instruction update) in Sandy Bridge while AMD on the other hand had FMA even in their first SSE5 extension set! This means SB will lack one of the strong features BD will have.

[Bo_Fox]

All right, at least that is a good thing, as it shows that AMD is serious about keeping up with Intel (if not actually beating Intel)...

[kl0012]

Chad ,Mr Fog writes optimization manuals for intel hardware,I think he knows "a bit better" how things stand in AVX land than you do . Not only him,but several Ace's members stated the new specification was released just in time to beat AMD's release of their new instruction set extension . And AMD did change their drex decoding scheme just to embrace the previous VEX decoding that was the basis of previous AVX revision.

It amazes me how far will you go in intel's defense. Are you their lawyer, spokesperson or what?

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.

Also note that intel has stated that they won't have FMA(the crucial instruction update) in Sandy Bridge while AMD on the other hand had FMA even in their first SSE5 extension set! This means SB will lack one of the strong features BD will have.

1. It is really doesn't mather why & when Intel changed his spec for FMA instructions - AMD's decoding scheme is similar but isn't compatable to Intel's decoding scheme. Intel's AVX extends many of SSE2/3/4 instructions to 256bit 3-operands mode and that feature is missing from AMD's new instruction set.

2. Changes made by Intel to FMA instructions (4-operand => 3 operand) nothing more then simplifying CPU hardware. If AMD can implement 4-operand instructions then it is very easy to convert such instructions to 3-operand (it is supported by default).

[Chad Boga]

Chad ,Mr Fog writes optimization manuals for intel hardware,I think he knows "a bit better" how things stand in AVX land than you do

He is someone who wants uniformity above all, thus his calls for a committee to oversee future x86 advancements.

Intel is concerned about making their products better and not worried about giving a helping hand to their rival(s).

You guys can hold hands and sing Kumbai Yah all day long, but that is not how the companies competing against each other operate and it is immature and out of touch with reality to not be cognisant of this.

Not only him,but several Ace's members stated the new specification was released just in time to beat AMD's release of their new instruction set extension.

Who gives a F#@% what several member's of Ace's stated, what a compelling argument.

Also note that intel has stated that they won't have FMA(the crucial instruction update) in Sandy Bridge while AMD on the other hand had FMA even in their first SSE5 extension set! This means SB will lack one of the strong features BD will have.

So if Intel are simply lacking a feature that AMD have, then the possibility exists that someone could code software that runs on AMD CPU's but not Intel CPU's, whilst all software coded for Intel would run on AMD.

That can only be in AMD's favour.

[informal]

It's only *one*(FMA) of the features intel will lack. The other is 4 operand(AMD) vs 3 operand(new intel spec,not the old one for mJanuary) instructions and it also brakes the compatibility.

I guess intel can keep on making changes until Ivy Bridge comes And I doubt AMD will make another change just to follow intel's suit. The point in this whole thing is to have a common instruction set extensions for both vendors so the software(and consumers in the end!) can benefit from it. Just pointlessly adding instructions that nobody will use and making new extension set revisions in order to break compatibility with other vendor is bad for all of us consumers(forget about intel and amd as companies,it is us who will get less value for the money if apps won't work on our new hardware or will work slower than what hardware could actually do).

PS I guess you have no comment on the proof you requested and I delivered(about revised avx spec)?

So despite you having no proof that Intel made the changes just to stuff up AMD, you will pursue that line of "thought" anyway.

Despite having no evidence that the changes that Intel made to their extension are not an improvement to them, you will still spread the "Intel is Satan" FUD.

As Paul DeMone alluded to, entitlement mentality gone mad.

Something went *mad* alright

[Chad Boga]

PS I guess you have no comment on the proof you requested and I delivered(about revised avx spec)?

How is that proof that Intel only did it to stuff up AMD and not because it made more sense for their product?

That it stuffs AMD around is no doubt true, but that doesn't prove that is why the changes were made.

[informal]

And what proof do you have it made more sense for their product?? They already said that FMA won't be in SB,even in the first revision of the AVX they published in 2008.So this means that the original and revised spec wouldn't affect SB design product cycle. The 4/3 operand instruction change bricks the compatibility even though these 2 companies were in continuous talks over patent agreement on avx specification and amd's implementation of it in their revised SSE5.So basically AMD will have to follow intel's suit and change the specs even though AMD has no time to waste since the specs WILL affect BD cores in less then 2 years from now.I guess AMD will not do such a thing since they just can't afford to mess ,again, with SSE extensions so close(relatively speaking)to their next major and probably most important uarchitecture launch.

There is a chance as Hans said,that AMD could be the first to publish the revised and now common extension set,but I wouldn't hold my breath.

[gumballguy]

Whos up for closing this thread?

I think we can all agree on a couple of basics:
1) By the definition of the word superset, it's not a superset
2) We'd all like AMD's instructions to give a performance boost
3) Intel's timing is questionable, but we're not the jury, and lots of these posts are angry/uninformed/both

That said, close close close!

It seems half my posts these days are begging for thread closure. Maybe we need a new website, www.xtremerant.com j/k

[Nedjo]

MS got nothing to say with AVX. And the reason is 95% of all companies, including Microsoft uses Intel compilers.

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...