New Zen information, AM3+ info, APU presentation, and video card information

CPU? Hell no, you mean GPU. CPU....I believe everyone acknowledges Intel is king. If I'm correct, AotS uses a lot of features that are expected in DX12, but whether they are used by other games is obviously not known yet, CPU/GPU.
Actually there aren't many games today that any current CPU wouldn't give adequate performance. Most games today are heavily GPU bound. Where I enjoy my FX8350 is when I have multiple windows open, usually a few games Simple ones though quite heavy on a CPU, Netflix and even this site at the same time. Extra cores have some serious multi-tasking muscle.
 
  • Like
Reactions: noko
like this
Remember the benchmark scales to 16 threads or more.

Around same clocks and cores. Zen 59FPS, 5960X 104FPS. This is pretty much the best case gaming scenario for Zen you ever see. And still a Haswell beats it by 76%. Not to mention how far the 6700K is ahead. 66% faster with half the cores and the same TDP. And that's with the Intel CPUs in question running higher quality mode here. Else the 6700K is 82% faster.

qY7K8jU.png
 
Last edited:
isn't AotS the benchmark tool used by AMD users by default to show "their massive superior CPU performance under DX12?" I thought it was that way..

Star Swarm was used to show how scaling over more then 4 cores would be that was pretty successful ....
But how can you show CPU performance on an API that primarily uses cpu to funnel data to the GPU, if anything you should expect performance increase is an API which is cpu bound like DX9/11 OpenGL.
To show of the cpu capabilities "they" tend to use some renderer (Cinebench) or other application in that direction...
 
idk aboot all these new aots numbers and shintai never said where he got/gets them...
first off the feng guys has disappeared from the aots database. none of his benchmark shows up and hes only run like six. second, the "zen" numbers seem very low and barely change going from low to crazy settings when there should be massive changes(had to look at pics on wccf link). and lastly, that article cagey linked(guessing 'cause the aots guy disappeared) is wccftech. oh and the games versions are vastly different. I think zen is still to far away to believe these "leaks".
 
idk aboot all these new aots numbers and shintai never said where he got/gets them...
first off the feng guys has disappeared from the aots database. none of his benchmark shows up and hes only run like six. second, the "zen" numbers seem very low and barely change going from low to crazy settings when there should be massive changes(had to look at pics on wccf link). and lastly, that article cagey linked(guessing 'cause the aots guy disappeared) is wccftech. oh and the games versions are vastly different. I think zen is still to far away to believe these "leaks".
Also add that I doubt there are any great drivers out for Zen yet so any results now even if only 3 months away are not likely anything more than "worst case scenario" and we can safely expect better.
 
Also add that I doubt there are any great drivers out for Zen yet so any results now even if only 3 months away are not likely anything more than "worst case scenario" and we can safely expect better.

Drivers? Its a CPU.
 
Drivers? Its a CPU.
And you apparently know little. There are chipset drivers and software must know how to use the CPUs architecture. That was the reason the 8150 looked so bad to begin with, Windows wasn't populating the cores correctly. But I guess it makes to much sense for you to acknowledge it.
 
And you apparently know little. There are chipset drivers and software must know how to use the CPUs architecture. That was the reason the 8150 looked so bad to begin with, Windows wasn't populating the cores correctly. But I guess it makes to much sense for you to acknowledge it.

The FX issue was entirely different and due to using entire modules first before moving to the next. Also it didn't change much. And its not about a driver, its about the kernel and scheduling.

There isn't such issue with Zen, since it uses the same approach that has been used for ages now with Intel. There isn't going to happen any magical performance fix from what you see today.

image007.png
 
There is microcode and UEFI/BIOS code that affects CPU performance

Not to mention that despite the 8c/16t 3.8GHZ-3.2GHz numbers being thrown about based on the part number alone we don't know if the ES was actually running at full speed, with all cores/HT enabled, with all the cache enabled, with or without debugging interfaces, etc. Assuming this wasn't spoofed to begin with.
 
The FX issue was entirely different and due to using entire modules first before moving to the next. Also it didn't change much. And its not about a driver, its about the kernel and scheduling.

There isn't such issue with Zen, since it uses the same approach that has been used for ages now with Intel. There isn't going to happen any magical performance fix from what you see today.

image007.png
Man you must be a shill or just plain ignorant. Skyrim is proof of nothing as for 2 reasons:

1. It uses X87 code which is disabled on FX CPUs

2. Skyrim is mostly single thread so any multithread efficiency enhancements will produce little to no results.

So you believe they can just produce a new CPU and plug it in and it works. No drivers or software tailoring needed.
 
Man you must be a shill or just plain ignorant. Skyrim is proof of nothing as for 2 reasons:

1. It uses X87 code which is disabled on FX CPUs

2. Skyrim is mostly single thread so any multithread efficiency enhancements will produce little to no results.

So you believe they can just produce a new CPU and plug it in and it works. No drivers or software tailoring needed.

There is no such thing as disabled x87 code on FX. An 8 core FX however only got 4 FPU units. And the x87 part is so tiny anyway that removing it would be the most silly you could do. Not to mention all the compatibility issues since software would outright fail to run.

Why dont you document your claims then? Instead you just keep attacking the messenger because you dont like the outcome. I can understand its a huge disappointment for you, but really, move on.

image010.png

image020.png
 
Last edited:
Cool thing is, the AMD section is going to become much more popular in the months to come. :) As far as online benchmarks go, I take all of them with a grain of salt or more like, a truck load of salt. (Oh, and I do mean ALL online benchmarks.) I have been burned in the past when those online benchmarks claimed the second coming of computing, I bought into it and then found that, guess what, it made little to no difference in my day to day computing and gaming.

Benchmarks do not really tell you much other than they are numbers on a graph. (Fun as the articles are to read though.) Hands on experience trumps online benchmarks any day of the week. ;)
 
Intel had a similar problem when HT first came out of windows assigning threads to the second thread in an occupied core before it assigned it to a different unoccupied core, but no benchmark like the ones shown are really going to show how scheduling improves performance since when it really matters isn't when the CPU is near full load but when it is relatively unloaded but has two high load threads where scheduling them on the same module/core causes both to perform less than if you assigned each thread to different modules/cores where they received full resources.

As far as CPU drivers/microcode goes there's never ever in the history of x86 computing where a "driver" or microcode update was released by a CPU mfg that caused an across the board performance increase for any CPU. Microcode updates generally fix erata and may at times give very slight performance boosts to specific instructions but are minor at best and generally unmeasurable (sub 1% range).
 
As far as CPU drivers/microcode goes there's never ever in the history of x86 computing where a "driver" or microcode update was released by a CPU mfg that caused an across the board performance increase for any CPU. Microcode updates generally fix erata and may at times give very slight performance boosts to specific instructions but are minor at best and generally unmeasurable (sub 1% range).

That's because by the time it hits retail they have worked everything out. When you are talking early engineering samples its a different story.
 
That's because by the time it hits retail they have worked everything out. When you are talking early engineering samples its a different story.

At this point in time validation is complete and production begun.
 
There is no such thing as disabled x87 code on FX. An 8 core FX however only got 4 FPU units. And the x87 part is so tiny anyway that removing it would be the most silly you could do. Not to mention all the compatibility issues since software would outright fail to run.

Why dont you document your claims then? Instead you just keep attacking the messenger because you dont like the outcome. I can understand its a huge disappointment for you, but really, move on.

image010.png

image020.png
It is well known X87 code is disabled after Phenom, hence your ignorance. And still old benches of Skyrim just prove your ignorance further. Maybe you should bow out while you can. I know I am right and if you still wish for me to link the X87 proof I will tonight, but you will regret it. Mark my words.
 
It is well known X87 code is disabled after Phenom, hence your ignorance. And still old benches of Skyrim just prove your ignorance further. Maybe you should bow out while you can. I know I am right and if you still wish for me to link the X87 proof I will tonight, but you will regret it. Mark my words.

Proof please.
 
It is well known X87 code is disabled after Phenom, hence your ignorance. And still old benches of Skyrim just prove your ignorance further. Maybe you should bow out while you can. I know I am right and if you still wish for me to link the X87 proof I will tonight, but you will regret it. Mark my words.

Well known by who? The Stilt even made a PI x87 patch to speed up x87 code on FX.

http://www.agner.org/optimize/instruction_tables.pdf

x87.png


Looking forward to the "regret" part.
 
That's because by the time it hits retail they have worked everything out. When you are talking early engineering samples its a different story.
Personally I'm not taking any of these so called leaks, esp of engineering samples as gospel. They might make me a bit nervous (or hopeful in cases where leaks show good results) but the only time I'll believe "this is the real performance" is when I read the [H] report on it. IPC isn't likely to change much from ES to retail since at that point design is pretty well locked in and all you're doing is optimizing and fixing erata, but I'm hoping clock speeds show some improvement in final silicon over what they show here.

Regardless it's not like MS has any code to add to make these new CPUs function. There might be new features they can use on them that require some recoding to make things work faster or more securely but you can readily install an unpatched XP install on any modern CPU platform and have it function at full speed, the only issue will be missing components from the chipset, CPU will run fine without any sort of microcode or any knowledge of the CPU by the OS.
 
WTF DO YOU THINK THE PATCH DID EXACTLY... X87 is blocked on FX processors, the patch unblocks them. UMFDASOAB.

x87 was never disabled as you claim. If x87 didn't work, you could pretty much kiss most 32bit software goodbye since it wouldn't run at all.

Few days when I was doing some low level testing for other purposes, I found something that didn't make any sense to me.
Now I roughly know what it is and what it does, but still some questions remain: Why does this "feature" exist in the first place and why it is activated on all 15h family parts. I would normally assume it is a workaround for some errata, however no bulletin exists for this one either. Also this feature does not exist in any documentation, or it does but only AMD has access to the required level. I find it hard to believe that it would be a design issue as the affected instructions work fine (but slowly) and it existed since early Zambesi revisions and, currently is still present in Richland and probably beyond (within family 15h)...

I'd say it is either a errata fix or a errata fix gone wrong. If it is a programming mistake which has gone un-noticed during the last two years ... That would make me just sad.
 
Last edited:
Not disabled on the cpu to be precise but not working in the motherboard BIOS.

If that was so, software would outright fail to run.

x87 was always working, the only difference is the speed. And as Stilt says, most likely due to a bug fix. The patch could simply reintroduce the bugs associated while giving a speedup.

Talking about the Stilt, after a decade of AMD and AMD support in response to Zen.

It seems that my "gut feeling" was right once again. Last week I went with a Intel CPU and nVidia graphics for the first time in nearly a decade :(
 
Last edited:
If that was so, software would outright fail to run.
x87 was always working, the only difference is the speed. And as Stilt says, most likely due to a bug fix. The patch could simply reintroduce the bugs associated while giving a speedup.
Talking about the Stilt, after a decade of AMD and AMD support in response to Zen.


Everyone but you knows that Zen won't beat Intel current offerings, so going with Intel was a safe bet, exciting news, really...
 
x87 is just floating point extensions. You can achieve the same result with a large int by just moving the decimal, though it won't be as fast obviously.
 
x87 is just floating point extensions. You can achieve the same result with a large int by just moving the decimal, though it won't be as fast obviously.
I don't think you understand how floats work... Double precision floats (64-bit) can represent numbers in the 1023 power range. Yeah good luck calculating an integer out to over a thousand digits and just moving the decimal.
 
If you had to, you could do it. I'd imagine if you needed such precise calculations you would have built your system around those requirements, though that doesn't make your point invalid.
 
Star Swarm was used to show how scaling over more then 4 cores would be that was pretty successful ....
But how can you show CPU performance on an API that primarily uses cpu to funnel data to the GPU, if anything you should expect performance increase is an API which is cpu bound like DX9/11 OpenGL.
To show of the cpu capabilities "they" tend to use some renderer (Cinebench) or other application in that direction...

It's the CPU FrameRate what you have to look at the AotS benchmark, that seems to scale pretty good with more cores, at the end is a benchmark but with a realworld game is better than nothing... there you can clearly see a big difference between that supposed Zen ES versus intel offerings.. I don't think those results could be any true.. Just competing with a 4670K? even to me that's pretty much MEH waiting to replace 2 overclocked i7 3930K but don't want to pay 1700$ for 6950X.

I don't know what even to think.. AMD FX CPU users always claim that intel have nothing to offer as a considerable upgrade for their FX8 CPUs... And then Zen it's only competing with a mere 4670K in one of the most scalable CPU game in the recent times and those same users suddenly are hyped? (not only in this forum but also others) saying things like "I would be happy with haswell-like level of performance" which it's 2013 technology.. will you upgrade to a Zen part? or Pendragon? Justreason? cageymaru? let's even think the chip is better than expected and it compete with the 4770K (not even the higher clocked 4790K) and that's considered to be a "not enough upgrade path for a FX8" user specially overclocked.. so, any reason beyond brand loyalty to go with zen?.

Only thing Im really hoping is to see the 4c/8t and 6c/12t way higher clocked because unlike intel fans I like to see Zen succeed..
 
x87 was never disabled as you claim. If x87 didn't work, you could pretty much kiss most 32bit software goodbye since it wouldn't run at all.
Ok so now I am home and ready to prove how moronic your statements are.

First of all here is the full link since you left out a lot of the information:
The Stilt's Book of Bulldozer - Revelations: Episode 2 (SuperPI / x87) - HWBOT forum

And this line especially:

Note: "x87 instruction (NRAC) block" -> Enabled means that the instruction is blocked (default on all 15h family APU/CPU/NPUs). Disabling it make the SuperPI "a bit" faster.

He does speak of errata but my point and one substantiated is the above point of X87 blocked. What I cant believe is that you had access to this information and yet acted as if there was no information containing the very word BLOCKED. Yet there it is in the same forum posts that you linked from.

I have learned over the years only a shill would post Skyrim benches as most are without the X87 patch and a great deal before some of the code rewrite where only a small amount of X87 may still exist. And in general they intentionally leave out information that doesn't speak to their agenda. I guess you could say they also have a slant to very piece of information they ferry to the masses but that could be said for a lot of posters that aren't shills.

So there's that, now for another point:

When you want to prove FX 8 core issues before and after the patches for core allocation, you don't post single thread games or programs that utilize all cores. Seriously that was incredibly asinine. The issue was as follows:

Cores are labeled in this order 0-1 2-3 4-5 6-7. Now originally windows/programs wanted to populate as follows: 0/1 then 2/3 then 4/5 then 6/7. After the fix it went more like this: 0/2 then 4/6 then 1/3 then 5/7. So in order to see the performance impact one must have a program that utilizes only 2-6 cores. Seriously I can not believe I have to point this out but after seeing most of the posts, I am not all that surprised.

Now back to the original discussion. Zen performance based on any leaks right now are nothing more than suspect. Based on what we know as fact, if it is clocked at 2.8-3.2Ghz it will perform at a minimum of 20% better than a 4.0Ghz 8350 per core. The original designation was 40% better than excavator which is at least 10% higher in IPC than Piledriver. That leads to an IPC advantage of 46% over piledriver. Now I have stated that the best proposal for what to expect is 25%, to account for any issues and the chance that the 40% claim was program specific or code specific. Now lets look at your post of benches. Do you not see any reason to not take too much stock in that bench? Seriously the game would still need some coding for that processor as well. I am not even sure if it would recognize the HT in Zen as of yet. But all that is just speculation and good fodder for discussion.

However you had no desire to discuss. The post of the leaked benches was to incite others. You have shown you have nothing but disdain for AMD hardware and obviously no interest in owning any of the hardware. So why is it you hang out in the AMD subforums? The state of forums is greatly in need of some cleaning.
 
It's the CPU FrameRate what you have to look at the AotS benchmark, that seems to scale pretty good with more cores, at the end is a benchmark but with a realworld game is better than nothing... there you can clearly see a big difference between that supposed Zen ES versus intel offerings.. I don't think those results could be any true.. Just competing with a 4670K? even to me that's pretty much MEH waiting to replace 2 overclocked i7 3930K but don't want to pay 1700$ for 6950X.

I don't know what even to think.. AMD FX CPU users always claim that intel have nothing to offer as a considerable upgrade for their FX8 CPUs... And then Zen it's only competing with a mere 4670K in one of the most scalable CPU game in the recent times and those same users suddenly are hyped? (not only in this forum but also others) saying things like "I would be happy with haswell-like level of performance" which it's 2013 technology.. will you upgrade to a Zen part? or Pendragon? Justreason? cageymaru? let's even think the chip is better than expected and it compete with the 4770K (not even the higher clocked 4790K) and that's considered to be a "not enough upgrade path for a FX8" user specially overclocked.. so, any reason beyond brand loyalty to go with zen?.

Only thing Im really hoping is to see the 4c/8t and 6c/12t way higher clocked because unlike intel fans I like to see Zen succeed..

The only reason I can think of why they tried it with Ashes of the Singularity is to test the hardware scheduler ...
But do you think that the 4 core part would scale a lot higher (lets say 4.5 ghz) would that be something you can expect of a first generation product ?

I can say that I would upgrade to Zen when I can see some progress, so far gaming with FX 8320E has not been bad but the step to something faster I would like even tho DX12/Vulkan should make things easier.
 
Last edited:
It's the CPU FrameRate what you have to look at the AotS benchmark, that seems to scale pretty good with more cores, at the end is a benchmark but with a realworld game is better than nothing... there you can clearly see a big difference between that supposed Zen ES versus intel offerings.. I don't think those results could be any true.. Just competing with a 4670K? even to me that's pretty much MEH waiting to replace 2 overclocked i7 3930K but don't want to pay 1700$ for 6950X.

I don't know what even to think.. AMD FX CPU users always claim that intel have nothing to offer as a considerable upgrade for their FX8 CPUs... And then Zen it's only competing with a mere 4670K in one of the most scalable CPU game in the recent times and those same users suddenly are hyped? (not only in this forum but also others) saying things like "I would be happy with haswell-like level of performance" which it's 2013 technology.. will you upgrade to a Zen part? or Pendragon? Justreason? cageymaru? let's even think the chip is better than expected and it compete with the 4770K (not even the higher clocked 4790K) and that's considered to be a "not enough upgrade path for a FX8" user specially overclocked.. so, any reason beyond brand loyalty to go with zen?.

Only thing Im really hoping is to see the 4c/8t and 6c/12t way higher clocked because unlike intel fans I like to see Zen succeed..
I will later next year. I am not rich in the least, always have to make the tough decisions and usually computer parts take the backseat. Once a year I can swing something but it wont be a $1000 swing.

I think a great deal of FX-pros like the system and how it operates and Intel just doesn't feel the same. For me I am not a fan of a company like Intel that does everything in their power not to follow even the basest of morality in business tactics. I flat out refuse to own Intel anything if I can help it. It is my personal choice and I have never let it guide my advice to others. If someone doesn't care and are fine with Intel and it fits their needs then that is what they need to get. Both Manofgod and myself just advised a poster in this subforum that an Intel was likely his best choice. Our fondness of AMD is just fine because we can in fact see reasons for either logically and don't let it impact our own advice to others.
 
Ok so now I am home and ready to prove how moronic your statements are.

First of all here is the full link since you left out a lot of the information:
The Stilt's Book of Bulldozer - Revelations: Episode 2 (SuperPI / x87) - HWBOT forum

And this line especially:



He does speak of errata but my point and one substantiated is the above point of X87 blocked. What I cant believe is that you had access to this information and yet acted as if there was no information containing the very word BLOCKED. Yet there it is in the same forum posts that you linked from.

I have learned over the years only a shill would post Skyrim benches as most are without the X87 patch and a great deal before some of the code rewrite where only a small amount of X87 may still exist. And in general they intentionally leave out information that doesn't speak to their agenda. I guess you could say they also have a slant to very piece of information they ferry to the masses but that could be said for a lot of posters that aren't shills.

So there's that, now for another point:

When you want to prove FX 8 core issues before and after the patches for core allocation, you don't post single thread games or programs that utilize all cores. Seriously that was incredibly asinine. The issue was as follows:

Cores are labeled in this order 0-1 2-3 4-5 6-7. Now originally windows/programs wanted to populate as follows: 0/1 then 2/3 then 4/5 then 6/7. After the fix it went more like this: 0/2 then 4/6 then 1/3 then 5/7. So in order to see the performance impact one must have a program that utilizes only 2-6 cores. Seriously I can not believe I have to point this out but after seeing most of the posts, I am not all that surprised.

Now back to the original discussion. Zen performance based on any leaks right now are nothing more than suspect. Based on what we know as fact, if it is clocked at 2.8-3.2Ghz it will perform at a minimum of 20% better than a 4.0Ghz 8350 per core. The original designation was 40% better than excavator which is at least 10% higher in IPC than Piledriver. That leads to an IPC advantage of 46% over piledriver. Now I have stated that the best proposal for what to expect is 25%, to account for any issues and the chance that the 40% claim was program specific or code specific. Now lets look at your post of benches. Do you not see any reason to not take too much stock in that bench? Seriously the game would still need some coding for that processor as well. I am not even sure if it would recognize the HT in Zen as of yet. But all that is just speculation and good fodder for discussion.

However you had no desire to discuss. The post of the leaked benches was to incite others. You have shown you have nothing but disdain for AMD hardware and obviously no interest in owning any of the hardware. So why is it you hang out in the AMD subforums? The state of forums is greatly in need of some cleaning.

NRAC doesn't block x87. Its a workaround for a bug.

Since you continue to humiliate yourself. Here is the instruction manual for the 15h family.
http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf

That's right, full x87 support. Official from AMD. Did you really in your wildest dreams imagine that construction cores couldn't handle x87 code? We can talk about the execution speed. But the support is there, else AMD would have sold 0 CPUs because software couldn't run.

And in terms of your Zen calculation. You are comparing 4/8 with 8/16 in a benchmark that scales to 16+ threads.
 
Last edited:
In terms of the Zen parts clocks.

"The 8c/95W variant's base clock is 2.8GHz, all core boost is 3.05GHz and maximum boost is 3.2GHz."

The low turbo delta may be an indicator that they are not TDP limited, but rather Fmax/domain limited.
 
Last edited:
NRAC doesn't block x87. Its a workaround for a bug.

Since you continue to humiliate yourself. Here is the instruction manual for the 15h family.
http://support.amd.com/TechDocs/47414_15h_sw_opt_guide.pdf

That's right, full x87 support. Official from AMD. Did you really in your wildest dreams imagine that construction cores couldn't handle x87 code? We can talk about the execution speed. But the support is there, else AMD would have sold 0 CPUs because software couldn't run.

And in terms of your Zen calculation. You are comparing 4/8 with 8/16 in a benchmark that scales to 16+ threads.
Man you are just trying to be obtuse. I never said the library or ability to execute X87 wasn't there but that it was being blocked. FX processors weren't running X87 but were instead running it with SSE2 (how it was told 3 years ago) which explains the speed differential. Also it was said the block was to circumvent paying Intel for the X87 license. Not a bad call considering the only real issue with it was Skyrim as it seemed to be the lone software left using it other than HWBot. And that is how it works by the by. If the code is X87 and the processor doesn't support it then the active code on the processor will run the code, a legacy support if you will, so no it will not crash, well as long as the supported code has the legacy support which most will.

And for the love of all that is holy, try reading a post and attempt to comprehend. It doesn't matter if one were 4 core and the other 82 core, the comparison was for IPC/single core throughput. Number of cores is irrelevant until we start talking multithread computation.
 
Back
Top