AMD Piledriver rumours ... and expert conjecture

Page 139 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
We have had several requests for a sticky on AMD's yet to be released Piledriver architecture ... so here it is.

I want to make a few things clear though.

Post a question relevant to the topic, or information about the topic, or it will be deleted.

Post any negative personal comments about another user ... and they will be deleted.

Post flame baiting comments about the blue, red and green team and they will be deleted.

Enjoy ...
 
Looks like the FMA3/FMA4 debacle was AMD trying to jump ahead of Intel's support of the code wich Intel changed from FMA4 to FMA3 after the fact. Who knows, Intel may change it yet again for haswell and AMD will be stuck with an unsupported code on both cpus.

Shows how Intel can control the market still by stating one thing, wait for your competition to adopt it, then going for something else at the last minute, leaving them high and dry. Unfortunately this is bad news for BD support for FMA4 as the code will be apparently abandoned by most.

http://news.softpedia.com/news/AMD-Trinity-Architectural-Preview-Part-II-267131.shtml
 
in my daughters HP G60 or G61 series (cant remember-darn old age)
she has a Sempron M100 single core 2.2ghz with ATI HD 4200 with 128 sideport ram
handles online gaming with no problem
we have played some of the more advanced MMOs for kids and worked fine
also streams Netflix HD and Youtube HD decently
wouldve been nice to have a dual core in the laptop but overall that Sempron single core handles general tasks well like browsing and MS office apps well

shame that they didnt get GCN into the Triintiy
not that VLIW4 isnt good for a laptop but I think the GCN wouldve given better wattage requirements if the HD 7xxx series is any indicator
 
Looks like the FMA3/FMA4 debacle was AMD trying to jump ahead of Intel's support of the code wich Intel changed from FMA4 to FMA3 after the fact. Who knows, Intel may change it yet again for haswell and AMD will be stuck with an unsupported code on both cpus.

Shows how Intel can control the market still by stating one thing, wait for your competition to adopt it, then going for something else at the last minute, leaving them high and dry. Unfortunately this is bad news for BD support for FMA4 as the code will be apparently abandoned by most.

http://news.softpedia.com/news/AMD-Trinity-Architectural-Preview-Part-II-267131.shtml

How dare Intel not support the codes to make AMD cpu's perform better, please stop it.
 
How dare Intel not support the codes to make AMD cpu's perform better, please stop it.
First off, AMD paid for the code in order to put it into their cpus.

If you feel that its right to disable hardware code that a company PAID FOR is ok, keep it to yourself. Its wrong period, no ammount of ignoring it can change that fact.

That would be like buying a hybrid electric vehicle with the electrical system disabled.
 
I dont know if anybody posted this article yet
a comparison of latest IGP from Ivy to AMD
http://www.legitreviews.com/article/1915/1/
So Llano IGP is still better than Ivy bridge, and AMD is calling for 50% or more in Trinity. Wither they get 50% or not, they have the edge over Intel in something Intel wants to have.
 
yes Llano did edge out IB but that is the closest Intel has come to AMD IGP
hopefully Trinity delivers on the graphics front
with improvements in the branch prediction and scheduling hopefully the CPU portion can be competitive
going by that article Trinity APU should have some decent gaming performance for an integrated mobile solution
I have said all along that when they can make an integrated platform that can play WoW and other MMMOs well plus handle some light duty gaming of modern titles that will go over well
even in the desktop market an integrated solution is desirable by OEMs looking to avoid adding an discrete solution in low end consumer desktops
besides the added cost of discrete GPU the OEMs also wouldnt have to put in higher wattage PSUs and we know how OEMs like to go cheap with the PSUs LOL

 
First off, AMD paid for the code in order to put it into their cpus.

If you feel that its right to disable hardware code that a company PAID FOR is ok, keep it to yourself. Its wrong period, no ammount of ignoring it can change that fact.

That would be like buying a hybrid electric vehicle with the electrical system disabled.


Well if what you say is true then AMD has a contract with Intel for these code, that would be breach
of contract and soon to be a wood shed moment for Intel. I'm thinking their a little more to this then
what you're saying right now.
 
noob2222 wrote :

That would be like buying a hybrid electric vehicle with the electrical system disabled.

If anyone was to do this I myself would consider you to be a moron, or someone who don't know
enough about hybrids to be shopping for one in the first place.
 
Well if what you say is true then AMD has a contract with Intel for these code, that would be breach
of contract and soon to be a wood shed moment for Intel. I'm thinking their a little more to this then
what you're saying right now.
Here is some interesting reading information.

http://www.agner.org/optimize/blog/read.php?i=49#49

Even after being told to fix it, they only "sorta" fixed it. Now you have to run the compiler with a special command to skip the vendor id check. Default still only uses SSE for GenuineIntel. Even that doesn't necessarily run the correct path, just makes it work a little bit better.

/QxO

Enables SSE3, SSE2 and SSE instruction sets optimizations for non-Intel CPUs

Here is some more reading material on it.

Ok, ICC is rarely used so AMD customers won't be so damaged, but Intel benchmarks AMD's processors using ICC and use this info for marketing, wich may hurt AMD's business, for example:

I just tried Intel C++ compiler version 10.1 with option /QxO as you suggested. It generates the following versions of code for common mathematical functions: SSE2, SSE3, SSE4.1 and non-Intel SSE2. It doesn't work on any CPU prior to SSE2. This is the only compiler option that makes it run reasonably on an AMD, but why are there two different SSE2 versions, one for Intel and one for AMD? When I hack the CPU-dispatcher and makes it believe that it is an Intel, it runs 50 - 100 % faster.

http://aceshardware.freeforums.org/cpuid-family-bits-added-because-of-flaw-in-intel-compiler-t428.html
 
Here is some interesting reading information.

http://www.agner.org/optimize/blog/read.php?i=49#49

Even after being told to fix it, they only "sorta" fixed it. Now you have to run the compiler with a special command to skip the vendor id check. Default still only uses SSE for GenuineIntel. Even that doesn't necessarily run the correct path, just makes it work a little bit better.

/QxO

Enables SSE3, SSE2 and SSE instruction sets optimizations for non-Intel CPUs

Here is some more reading material on it.

Ok, ICC is rarely used so AMD customers won't be so damaged, but Intel benchmarks AMD's processors using ICC and use this info for marketing, wich may hurt AMD's business, for example:

I just tried Intel C++ compiler version 10.1 with option /QxO as you suggested. It generates the following versions of code for common mathematical functions: SSE2, SSE3, SSE4.1 and non-Intel SSE2. It doesn't work on any CPU prior to SSE2. This is the only compiler option that makes it run reasonably on an AMD, but why are there two different SSE2 versions, one for Intel and one for AMD? When I hack the CPU-dispatcher and makes it believe that it is an Intel, it runs 50 - 100 % faster.

http://aceshardware.freeforums.org/cpuid-family-bits-added-because-of-flaw-in-intel-compiler-t428.html

Then AMD know what they need to do then right?
 
Then AMD know what they need to do then right?

Your attitude that whatever Intel does that is good for Intel is ok because that's business is disturbing to me and I don't mind, just this time, saying so. You and those who think like you need to develop a sense of responsibility even if Intel is incapable, seemingly, of doing so. The U.S.A. has laws for such things, and we need them.

Do you even think about what you post or are you just arguing?
 
Your attitude that whatever Intel does that is good for Intel is ok because that's business is disturbing to me and I don't mind, just this time, saying so. You and those who think like you need to develop a sense of responsibility even if Intel is incapable, seemingly, of doing so. The U.S.A. has laws for such things, and we need them.

Do you even think about what you post or are you just arguing?
Some people when they have trouble going to sleep at night, count sheep.

When insomnia hits me, I just count the egregious acts of evil committed by Intel.
 
Piledriver using FMA3 (like Intel) instead of FMA4 (Bulldozer). Also adding F16C.

http://vr-zone.com/articles/amd-trinity-apu-preview-evolution-or-devolution-/15716.html

Actually FMA3 and FMA4 are both Intel's. Originally Intel was going to use a Fused-Multiply-Add instruction that could handle four numbers are once. Intel gave the instruction extension to AMD (required by their cross licensing agreement) and AMD started implementing it in BD. Later Intel announced that it would instead use a FMA instruction that could handle three numbers at once instead of a four part one. It was too late in BD's design cycle for AMD to change it and thus BD got released with Intel's older spec.

Of course the fact that Intel had somehow had time to integrate FMA3 into SB has lead to some speculation that they intended to use it the entire time. Again that is purely speculation, Intel is fully capable of spending ridiculous amounts of money to make a major change (instruction set wise) in a very small period of time.

AMD going to FMA3 makes sense for the same reasons they implemented SSE2/3/4. Software producers are not going to spend the money making multiple binarys, AMD's best strategy has always been to make their CPU's as compatible with Intel's as possible at the instruction level. All they need to do now is allow their CPUID to be changed in software.
 
Anything that carried the "Optimizes for Intel" logo is software that has been compiled, at least partially, with the Intel Compiler. Intel's compiler is expensive but they offer it at a discount to big game manufacturers along with software optimization support. And since we're constantly using "real world single player timed demo loop games" for benchmarks this would allow Intel to give itself a boost in performance numbers. We may be the enthusiasts but many buyers will buy what the reviewer of "PC Magazine" or even gaming magazines say they should buy.

Its the same reason Apple and Adobe give / discount sell their products to schools.
 
Anything that carried the "Optimizes for Intel" logo is software that has been compiled, at least partially, with the Intel Compiler. Intel's compiler is expensive but they offer it at a discount to big game manufacturers along with software optimization support. And since we're constantly using "real world single player timed demo loop games" for benchmarks this would allow Intel to give itself a boost in performance numbers. We may be the enthusiasts but many buyers will buy what the reviewer of "PC Magazine" or even gaming magazines say they should buy.

Its the same reason Apple and Adobe give / discount sell their products to schools.
So are you saying, the games are rigged before TWIMTBP?
 
Your attitude that whatever Intel does that is good for Intel is ok because that's business is disturbing to me and I don't mind, just this time, saying so. You and those who think like you need to develop a sense of responsibility even if Intel is incapable, seemingly, of doing so. The U.S.A. has laws for such things, and we need them.

Do you even think about what you post or are you just arguing?

Honestly I don't care what you like or dislike about my feeling on anything they are my feeling
not yours.
 
So are you saying, the games are rigged before TWIMTBP?

Not so much rigged as just "sponsored" by Intel. Ever notice how so many TV dramas have their cast members using Apple notebooks for ~everything~. The lawyer/doctor/engineer/geek/whatever runs over to their computer to "do something geeky" and BAM you get a shot of the back of the notebook with a big apple logo. Apple sponsors many media productions by investing money into them with the provision that they get shots in with the cast members using "Apple" products during the show. It's basically a commercial hidden inside the show, same with coke / pepsi and various other product manufacturers. Reviewers of computer magazines use "gaming" benchmarks for lots of their ratings, so by sponsoring game developers Intel can ensure they get favorable reviews. Also note that gathering sponsors is the job of the production company not the development studio, so while the producer can line up the deal the development company can still say no. ATI / NVidia did this for years, AMD only recently entered into this practice, they have lots of work to do to develop the relationships with the big game production companies and to ensure their products are properly show cased.

This practice isn't bad, its just market forces and commercialism at work. Hiding and not reporting it is very bad. This is why I think every site that does any form of professional benchmarking should make a note of which HW "sponsors" were involved with the products their benchmarking as a form of disclosure. The nondisclosure of this information is what leads to all the finger pointing and claims of bias on both sides.
 
Developers can optimize anyway they want, use the compiler they want and support the hardware they want. Problem is, when the Intel machine sweet talks you, it's hard to say no. They have the resource advantage and no one is willing to say no when they "sponsor" your stuff.

And in another note, AFAIK, the cross licensing agreement with AMD is supposed to forbid the CPUID change on every licensed x86 CPU. VIA doesn't need to comply, since they also own part of x86 and such. I could be remembering this wrong, though. But it's pretty weird you can not trick the code; or at least, I've never heard of a way to do so.

Cheers!
 
Little more detail on the FMA3 vs FMA4 fiasco.

History

The incompatibility between Intel's FMA3 and AMD's FMA4 is due to both companies changing plans without coordinating coding details with each other. AMD changed their plans from FMA3 to FMA4 while Intel changed their plans from FMA4 to FMA3 almost at the same time. The history can be summarized as follows:

August 2007: AMD announces the SSE5 instruction set, which includes 3-operand FMA instructions. A new coding scheme (DREX) is introduced for allowing instructions to have three operands.[5]
April 2008: Intel announces their AVX and FMA instruction sets, including 4-operand FMA instructions. The coding of these instructions uses the new VEX coding scheme which is more flexible than AMD's DREX scheme.[6]
December 2008: Intel changes the specification for their FMA instructions from 4-operand to 3-operand instructions. The VEX coding scheme is still used.[7]
May 2009: AMD changes the specification of their FMA instructions from the 3-operand DREX form to the 4-operand VEX form, compatible with the April 2008 Intel specification rather than the December 2008 Intel specification.[8]
January 2012: AMD announces FMA3 support in future processors codenamed Trinity and Vishera based on Pildriver architecture. [9]

It is currently uncertain whether the 3-operand VEX coded form (here called FMA3) or the 4-operand form (FMA4) will be the dominating standard in the future. It is also possible that future processors will support both forms.
 
Developers can optimize anyway they want, use the compiler they want and support the hardware they want. Problem is, when the Intel machine sweet talks you, it's hard to say no. They have the resource advantage and no one is willing to say no when they "sponsor" your stuff.

And in another note, AFAIK, the cross licensing agreement with AMD is supposed to forbid the CPUID change on every licensed x86 CPU. VIA doesn't need to comply, since they also own part of x86 and such. I could be remembering this wrong, though. But it's pretty weird you can not trick the code; or at least, I've never heard of a way to do so.

Cheers!
You are right, look what happens when you play with vendor id strings on the nano.

http://arstechnica.com/hardware/reviews/2008/07/atom-nano-review.ars/6
 
Status
Not open for further replies.