The Book of Bulldozer - Revelations: Episode 2 (SuperPI / x87)

Exactly two year ago, when I tested a Bulldozer based Zambesi CPU for the first I was shocked.
The early sample units were even hotter and slower than the final silicon revision CPUs, which finally were released four months later.
One of the largest single let-down came from the way back: SuperPI.

SuperPI mainly uses legacy x87 instructions which have been almost completely superceded.
SuperPI doesn't show any indication what so ever about SMP performance as it can only utilize a single thread. On top of that it has no real world use or purpose as there are newer programs which can calculate PI almost 100 times faster.

Still, SuperPI can almost be considered as a industry standard.
Nowdays it is generally a VERY poor indicator of real world performance, yet it is so addictive for any old school overclocker. It scales very well along with the CPU/NB/DRAM/IO performance and tweaking it is a big challenge. An overclocker who hasn't ever benched SuperPI simply doesn't exist.

SuperPI has a special place in my heart simply because it was one of the first benchmarks I ever ran... almost 14 years ago...

So, why are all of the 15h (Bulldozer) based CPU/APU/NPUs performing so bad in SuperPI?
Some people say it is because 15h family has 50% less FPs per core than the preceeding 10h family.
In 15h family a compute unit (two cores) share a FP when the 10/12h family had a dedicated FP for each of the cores.

If this would be the only reason, the issue would be solved when the "slave" core of the CU is disabled, leaving a "private" FP for the "master" (BSC) core. However this is not the case and it even shouldn't be as SuperPI is single threaded, remember?

The caches on 15h family have higher latency than 10h family for example, and SuperPI happens to love large & low latency caches.
15h family was initially designed for high frequencies. Just like the F1 engines, they produce no power at low revs. And unfortunately it currently doesn't seem to be possible to build an engine capable reving high enough. We might discuss more about the caches in "Episode 3"... If possible.

Agner Fog from Copenhagen University College of Engineering has made an excellent document about the instruction latencies of the modern CPUs.

Values for 10h family start from page 26, while 15h family values are located at page 36.

Anyway...

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 :shakes:

Parts affected: AMD Barracuda (Zambesi, Vishera), AMD Comal (Trinity, Richland), AMD Virgo (Trinity, Richland)

Effect: A massive performance hit in application heavily utilizing x87 instructions.

Negative effects: TBD, none found yet. The performance in non x87 applications remains the same or improves very slightly. No instability, increased power consumption, reduced overclockability or anything else abnormal has been observed. However the final conclusion requires far more extended testing than I am able to do myself.

After the fix has been applied SuperPI shows 18-30% improvement in performance.
Bigger the calculation, bigger the improvement.

Since this kind of fix is quite unheard of, I knew that I would be crucified if I would make such claims without any providing evidence.

I generally hate to do videos however this time it was mandatory.

I apologize the quality, 1080p is available but the quality is quite grainy due poor lightning.
It was a cloudy day in Helsinki today.

The video shows few important things:

- In the video the fix is called as "The Plow of Bulldozer"
- SuperPI 1.5 XS Mod validated by online MD5 checksum
- CPU-Z 1.64.3 x32 validated by online MD5 checksum (can be found from Stasio's CPU-Z thread)
- The clocks are being shown during the calculation (look for the affinity and CPU-Z core selection)
- An external clock reference is provided (to prove there is no tampering with the timers, i.e. "Lab Burst" by MSI)
- The air cooled setup is shown and so are the CPU temperatures (HWMonitor)


http://www.youtube.com/watch?v=3w7ZiS_ScUg


For the 32M SuperPI run (time) you might want to look a reference from HWBot Piledriver 5G challenge thread.
http://hwbot.org/submission/2386335_...n_14sec_718ms/

39 seconds better time with stock CPU clocks (4.1GHz, NB 2500, MEMCLK DDR-2400) than on 5GHz Trinity with 2777MHz NB and DDR-2666 memory clocks.

Since I 'happened' to have some LN2 in my disposal, I decided to do some high clock SuperPI runs on Richland.

http://img834.imageshack.us/img834/9...rpi1mtpobd.png

http://img526.imageshack.us/img526/9...rpi32mtpob.png

AMD 32nm SuperPI 32M record taken easily.
Tomorrow when I throw in a Vishera, the reign of 10h should be finally over ;)

All of the runs are either completely or partially on video.
Will upload them once I have time to edit them. I've been filming around 28GB worth of video during the last 48h hours.

FAQ (as I would assume):

Q: Does it help on my grandma's Palomino Athlon or on my Phenom / II or 12h Llano?
A: NO

Q: Does it work on my xxx branded motherboard?
A: It has nothing to do with the motherboard, or the OS or any other component. If the CPU says AMD on it and it is Bulldozer based then it will work.

Q: When will the fix come available to public?
A: Once I have started and finished the programming. The program is quite simple really, only some minor hardware detection features required.

And now...
I will go and have atleast a proper meal and sleep.
During the last 72 hours I have worked 45 hours, currently I probably look and smell like a pirate.

Please don't send me pm regarding the software.
It will be available to everyone at the same time.
If you have something to ask, please do. I'll answer when I have time.

"The OP will surely deliver. Let's just wait."
Just kidding :cool:

Soon.

Update on 06/21/2013: Available for download. Please check post #42 for the link.

[B]Update on 06/26/2013: Version R1.02B available Post #75

Very interesting read, whoo! :up:

O.o

I thought FX and such chips sucked at x87 since they didn't have the hardware for it...that it's "software emulated".

Are you saying the X87 FPU exists again?



:rofl:

I've been wondering why AMD has sucked in SPi going all the way back to the A64 X2's...
Not sure your findings with BD are relevant, but it was weird (even back then) that X2's crushed P4's in everything except SPi. :rolleyes:
You invest so much time and have awesome skills when it comes to AMD's offerings!

Can't wait to see your patch/fix bud! I've never been a huge fan of synthetic benchies though.
It'll be interesting to see if it offers a performance boost in any other areas. :yepp:

I officially offer you "GURU Status"! :bows::bows::bows::D
AMD should put you on the payroll!

Verrrry interesting

I haven't benched in years (since conroe was first released) but I was always a little disappointed and left wondering why AMD cores were fairing so badly when tortured compared to intel

Was it just bad mArch design, MS windoz/benchmark apps not optimized to work well with AMD parts along with all the conspiracy theories.................maybe we will find out soon :)

Can you get into direct contact with AMD engineers to tell them your findings? Is hard to believe that a errata fix for around the size of Barcelona TLB bug or P5 x87 wasn't fixed in two entire generations.

More interesing will be your fix. I'm expecting a run-every-boot application that changes some bit in a internal register that makes Bulldozer x87 to disregard the time-consuming workaround. Do you expect that it would be included as a fix via microcode in newer BIOS upgrades? Besides, can you guess what it was supposed to fix?

Very interesting finding The Stilt!

Have you tested other x87 code to see if it improves performance there as well?

Quote:

---

Originally Posted by cadaveca

I thought FX and such chips sucked at x87 since they didn't have the hardware for it...that it's "software emulated".

Are you saying the X87 FPU exists again?

---

How do you think 15h generation can run x87 code then? Of course they have hardware for it, it's part of basic ISA .
They sucked at it since apparently there is some "un-optimization" going on in hardware when these instructions are in question. That's how the chip was designed, the latencies for x87 instructions are noticeably higher vs 10h generation.

Test physx for me, like vantage and mafia 2.

When this fix is applied, does it retain even if cpu is taken out of socket, or do people need to apply it more often than once`?

It depends... If it's a microcode patch you'd have to do it each time the system booted up (easily done with a start up task) or if it's an OS patch, once until you re-install the OS.

You won't have to physically modify the CPU at all.

Quote:

---

Originally Posted by cadaveca

I thought FX and such chips sucked at x87 since they didn't have the hardware for it...that it's "software emulated".

Are you saying the X87 FPU exists again?

:rofl:

---

There is no dedicated x87 FPU / co-processor thats for sure.

AMD documents: #47414 (Software Optimization Guide for AMD Family 15h Processors) & #26569 (AMD64 Architecture Programmer?s Manual Volume 5: 64-Bit Media and x87 Floating-Point Instructions) should explain how the x87 instructions are executed on 15h family. The latter one I cannot provide as it is confidential (?).

Quote:

---

Originally Posted by zir_blazer

Can you get into direct contact with AMD engineers to tell them your findings? Is hard to believe that a errata fix for around the size of Barcelona TLB bug or P5 x87 wasn't fixed in two entire generations.

More interesing will be your fix. I'm expecting a run-every-boot application that changes some bit in a internal register that makes Bulldozer x87 to disregard the time-consuming workaround. Do you expect that it would be included as a fix via microcode in newer BIOS upgrades? Besides, can you guess what it was supposed to fix?

---

I have no interaction what so ever with AMD engineers, unfortunately.

There are three different ways the fix could be activated permanently.
AMD could release either a new microcode or AGESA version which reconfigures the necessary registers or a motherboard vendor could add a small piece of custom code to be activated during the CPU initialization.

The registers can be also controlled 'in flight', which is the way I am doing it.

Neither AGESA or the microcode seem to have any interaction on this feature.
I've checked most of the AGESA and microcode versions for 15h family since early 2011.
I cannot see any indication that any of these has ever taken any action to control this feature.

This would indicate that it is not a errata workaround of anykind.
The value has been left to default setting as defined by the RCU/ROM/Fuse of the CPU (i.e. no action taken at any point).

Since AMD uses encrypted microcodes I could not verify their part on this feature any other way than disabling the microcode completely.
While it changed several other things, it had no effect to this feature. Just as I expected.

Quote:

---

Originally Posted by Lightman

Very interesting finding The Stilt!

Have you tested other x87 code to see if it improves performance there as well?

---

Like said, the x87 has been almost completely superceded.
This makes it actually quite hard to even find a application which would still fully utilize x87 instructions, especially when newer instructions are available (supported). I should be able to disable all of the newer instructions to force the program to execute x87 only, however it might cause some undefined behavior. I haven't had time to try that yet.

There are even more x87 related options which certainly look interesting, so I will need to try them at some point too.

Quote:

---

Originally Posted by Mechanical Man

When this fix is applied, does it retain even if cpu is taken out of socket, or do people need to apply it more often than once`?

---

The fix needs to be applied each and every time after a power cycle (cold / warm reset, shutdown, etc.).
Unless there will be a AGESA / microcode update of course. I would not hold my breath on that as only AMD knows entirely what this feature does and why it is turned on, on 15h family in the first place.

Quote:

---

Originally Posted by informal

How do you think 15h generation can run x87 code then? Of course they have hardware for it, it's part of basic ISA .

---

Don't get mad for what AMD reps told me. I was told this exact statement for 8150 launch, 8350 launch, APU launch reviews I did...I guess you didn't see the sarcasm in my post, however.

Quote:

---

Originally Posted by The Stilt

There is no dedicated x87 FPU / co-processor thats for sure.

AMD documents: #47414 (Software Optimization Guide for AMD Family 15h Processors) & #26569 (AMD64 Architecture Programmer?s Manual Volume 5: 64-Bit Media and x87 Floating-Point Instructions) should explain how the x87 instructions are executed on 15h family. The latter one I cannot provide as it is confidential (?).

---

I already have that, thanks. :p Very interested to see how this works out, although...who's gonna get any use out of it...just benchers? So can you make updated AMD SPi32m? ;)

Here are some of the results for other applications.
As said, most of the results are within the margin of error.

The only program that shows are larger difference is Linpack, however I find the result as inconclusive for following reason: The Linpack had to be patched in order to make it execute on AMD CPUs in the first place. It also fully optimized for Intel ONLY.

Note: + = improvement over default
ME = Margin of error

Code:

---


BarsWF SSE2 (MD5 Brute-Force) - Difference: +0.032% (ME)

Lame V3.99.5 (MP3) - Difference: -0.4% (ME)

Fritz 4.2 (Chess) - Difference: +0.042% (ME)

Euler3D 2.2 (Stars CFD) - Difference: +0.039% (ME)

wPrime 2.09 (1024M) - Difference: -0.308% (ME)

Multicore PI 4.0.0.0 - Difference: -0.002% (ME)

LuxMark 2.0 (Sala Scene) - Difference: 0.000% (ME)

Linpack 11.3.008 (Read the note!) - Difference: -3.093%

Fluidmark 1.5.2 - Difference: -0.850% (ME)



7-Zip 9.30 Alpha x64 (Compress, 32M Dict.) - Difference: 0.000% (ME)

7-Zip 9.30 Alpha x64 (Decompress, 32M Dict.) - Difference: 0.000% (ME)

7-Zip 9.30 Alpha x64 (Compress, 64M Dict.) - Difference: +1.447 % (ME)

7-Zip 9.30 Alpha x64 (Decompress, 64M Dict.) - Difference: +0.032% (ME)



WinRar 5.0 Beta5 x64 - Difference: -0.259% (ME)



Y-Cruncher 0.61 (x86 SSE3 - Single Thread, Chudnovsky 50M) - Difference: +0.689% (ME)

Y-Cruncher 0.61 (x86 SSE3 - 4 Threads, Chudnovsky 50M) - Difference: +0.850% (ME)

Y-Cruncher 0.61 (x86 SSE3 - Single Thread, Ramanujan 50M) - Difference: +1.305% (ME)

Y-Cruncher 0.61 (x86 SSE3 - 4 Threads, Ramanujan 50M) - Difference: +0.820% (ME)



Y-Cruncher 0.61 (Kasumi x64 SSE3 - Single Thread, Chudnovsky 50M) - Difference: +0.768% (ME)

Y-Cruncher 0.61 (Kasumi x64 SSE3 - 4 Threads, Chudnovsky 50M) - Difference: +1.169% (ME)

Y-Cruncher 0.61 (Kasumi x64 SSE3 - Single Thread, Ramanujan 50M) - Difference: +1.715% (ME)

Y-Cruncher 0.61 (Kasumi x64 SSE3 - 4 Threads, Ramanujan 50M) - Difference: +0.814% (ME)



Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - Single Thread, Chudnovsky 50M) - Difference: +0.766% (ME)

Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - 4 Threads, Chudnovsky 50M) - Difference: +0.424% (ME)

Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - Single Thread, Ramanujan 50M) - Difference: +1.743% (ME)

Y-Cruncher 0.61 (Nagisa x64 SSE4.1 - 4 Threads, Ramanujan 50M) - Difference: +0.821% (ME)



Y-Cruncher 0.61 (Ushio x64 SSE4.1 - Single Thread, Chudnovsky 50M) - Difference: +0.702% (ME)

Y-Cruncher 0.61 (Ushio x64 SSE4.1 - 4 Threads, Chudnovsky 50M) - Difference: +0.857% (ME)

Y-Cruncher 0.61 (Ushio x64 SSE4.1 - Single Thread, Ramanujan 50M) - Difference: +1.489% (ME)

Y-Cruncher 0.61 (Ushio x64 SSE4.1 - 4 Threads, Ramanujan 50M) - Difference: -0.190% (ME)



Y-Cruncher 0.61 (Hina AVX x64 - Single Thread, Chudnovsky 50M) - Difference: +0.835% (ME)

Y-Cruncher 0.61 (Hina AVX x64 - 4 Threads, Chudnovsky 50M) - Difference: +0.891% (ME)

Y-Cruncher 0.61 (Hina AVX x64 - Single Thread, Ramanujan 50M) - Difference: +0.807% (ME)

Y-Cruncher 0.61 (Hina AVX x64 - 4 Threads, Ramanujan 50M) - Difference: +0.210% (ME)



3DMark03 - Difference: -0.192% (ME)

3DMark05 - Difference: +0.291% (ME)

3DMark06 - Difference: -0.255% (ME)

3DMark Vantage (Performance) - Difference: -0.186% (ME)

3DMark11 (Performance) - Difference: -0.060% (ME)

3DMark Fire Strike - Difference: -0.136% (ME)

---

I'm curious to see if it changes Cinebench 11.5r single thread score?
I'm doubting it would.

Quote:

---

Originally Posted by demonkevy666

I'm curious to see if it changes Cinebench 11.5r single thread score?
I'm doubting it would.

---

No.
Neither does x264 r2334.

Quote:

---

Originally Posted by The Stilt

No.
Neither does x264 r2334.

---

So it's only for anything that is x87 fpu coding,finding anything that still uses x87 is kind of hard.

Skyrim I think is one game that still uses it.

so it's not going to make any thing else faster

Hmm I see you have tested yCrunsher, too, but only the "modern" versions. There is also an old x87-one, which however was deleted in the newest 0.61 version (everybody has at least SSE3 these days, hasnt it?). If you have time please download the old 0.5.5 package:
http://www.numberworld.org/y-crunche...0(fix%202).zip

and then make a test run with the "x86.exe", I assume that it uses x87. What else can it use ;-)
The build description is:

Quote:

---

Version: x86

No Processor Specific Tuning


Target Systems:
- Legacy x86.

---

Apart from that I wonder what "magic" is switched on. Could it maybe be some FDIV-circuits? I know that the Integer DIV-Units are enabled for the Piledriver cores (even though they were already there at the first Bulldozers, but they were deactivated). Now an FDIV-Unit is announced for Steamroller - I wonder if there is already some test-unit for that purpose integrated in the current core versions.

Nice find! It would've had helped Bulldozer not to look so dull in the beginning if it had been activated. SuperPi is SuperPi, we all trust in it. I will install it for sure just to know my x87 is switched on again (dammit, maybe its a licensing issue to microsoft?)

Quote:

---

Originally Posted by Opteron146

Hmm I see you have tested yCrunsher, too, but only the "modern" versions. There is also an old x87-one, which however was deleted in the newest 0.61 version (everybody has at least SSE3 these days, hasnt it?). If you have time please download the old 0.5.5 package:
http://www.numberworld.org/y-crunche...0(fix%202).zip

and then make a test run with the "x86.exe", I assume that it uses x87. What else can it use ;-)
The build description is:


Apart from that I wonder what "magic" is switched on. Could it maybe be some FDIV-circuits? I know that the Integer DIV-Units are enabled for the Piledriver cores (even though they were already there at the first Bulldozers, but they were deactivated). Now an FDIV-Unit is announced for Steamroller - I wonder if there is already some test-unit for that purpose integrated in the current core versions.

---

I?ll try that as soon as I can.

The same fix seems to be required on Steamroller too.

Quote:

---

Originally Posted by The Stilt

I?ll try that as soon as I can.

The same fix seems to be required on Steamroller too.

---

You are such a tease..:shocked:

Quote:

---

Originally Posted by The Stilt

I?ll try that as soon as I can.

---

Great, thanks :)

Quote:

---

The same fix seems to be required on Steamroller too.

---

Ok then I honestly have no clue what is going on ... mysterious.

The Stilt

I am pretty sure demonkevy666 is right about Skyrim using x87 code. I remember one of the first big patches included some community modders programming work as he found they had a :banana::banana::banana::banana:load of x87 code and he optmised some areas with SSE2 if I remember correctly.
Not sure how much x87 remains, but it could be interesting. It would also suggest to me that it is likely Bethesda has used x87 code in the previous versions of the elderscroll games.

Physx by Nvidia also uses x87 code over SSE versions. That could be interesting to test. Games that heavily use physx too could be interesting to test, Batman from 2010.

Other games heavily using physx I have found, Warframe, The secret world, Arma3, PlanetSide2, Hawken, any U4E game...

Quote:

---

Originally Posted by Oese

I will install it for sure just to know my x87 is switched on again (dammit, maybe its a licensing issue to microsoft?)

---

It is not switched off, it works just slower than it could. The question is why... I dont think that it is a licensing problem, x87 is more than 20 years old. Yes MS says that nobody should use it any more, but still that is no reason for AMD to handicap their own CPU.

I would suggest to try to get an ASM programmer to make a x87 benchmarking program. I recall seeing several mini programs that did things like that. Here is one.

Gentlemen...

We have a Ridgeback down!

http://www.youtube.com/watch?v=mElg7ioNmIM

Few "goosfraba's" were required for the obvious reason in the end of the video...

Stilt you are the man!

I have some questions and some (maybe) helpful information for everyone.

I have been playing with recompiling software used in benchmarks in Gentoo and comparing them to my Windows scores.

So far I have tested:

x264: about 5% to 10% increase in Gentoo
LAME: about 60% increase in Gentoo
Blender: about twice as fast in Gentoo.

Can you perhaps give LAME a shot with this? And maybe Blender?

Looking forward to the release. Is it possible to make a Linux version? Perhaps GCC with bdver2 flags can compile around this issue and in Windows we don't get this sort of optimization. Or perhaps I could even add more to it.

If you are looking for data I would gladly play with this patch and compile open source benchmarks with whatever settings and share the data.

I have a theory that the benchmarks where AMD does really poorly on (LAME, SuperPI, etc) are being artificially limited by software or whatever. Recompiling in GCC and seeing 60% or 100% or better gains is pretty much unheard of in the Gentoo user world.

I've wrapped up my tests on LN2 with Richland and everything else too, so I can put some hours on this matter in the weekend.
I'll try the fix with games in which AMD especially is performing poorly at.

After the fix has been released, I'll start fine tuning prefetchers and predictors to see if there is any general or application specific improvements to be juiced out of Bulldozer :)

Man, you are the MAN! Awesome, I have now happy day because you :)! Wow. IF you have still some LN2, can you test Superpi 32M for "wr" with Vishera?

awesome with such tuning in advanced level. im impressed! :up:

I wonder if there are other PI versions that use newest instructions and compare to Intel's?

Hihi,

just remembered another application. There is a Boinc project called "simap" (http://boincsimap.org/boincsimap/), they have not changed their program since ages, it is still x87 based. The core algorithm they used exists already in an SSE2 version, which is ~8 times faster according to a scientific paper of the programmer, but they dont use it. Maybe your patch can help Bulldozer a bit. All work-units are calculated twice for testing on another machine, so you should be able to detect potential calculation bugs. Just check if your patch has a positive effect on the speed and then let it run a few days ;-)

cheers

I'm going to try and and write a program that calculates the digits of Pi and then compile it with GCC for different optimization flags.

Wow, so much knowledge here...I'm really interested to see how this pans out. Major props!

There are two kind of news bad and good ones.

Let's get rid of the bad ones first:

Originally I tested this fix on three different CPU/APUs (Richland, Trinity and Vishera).
When I went to verify the effects of the fix on Zambezi the system crashed immediately once the necessary changes were written.

After some research I noticed that these registers do not respond on Zambezi based CPUs.
Upon reading all of them return null values and crash the system unless a special method is used.
At first it appeared that these registers do not exist on Zambezi, however after digging a bit deeper I found indication that the registers are there... But for some reason AMD seem to have protected them with a ESI/EDI password on Zambezi.

They do not require any passwords on any Piledriver based APU/CPU.

So the fix will not be available for Zambezi users.
Sorry for the massive let-down :(

The the good news:

The software is pretty much finished.
It should be available for download within this week.

After the let-down on Zambezi I felt that something had to be done for Zambezi too.
While it does not result as massive boost as the original fix does it still gives something:

SuperPI 1M: > 1 second improvement
SuperPI 8M: > 10 second improvement
SuperPI 32M: > 35 second improvement

It is called as "Zambezi Stack Special (PD)".
Note: There might also be some performance retardation in some applications when enabled (Zambezi vs. Vishera effect).

Zambezi is significantly faster than Vishera in SuperPI by default so the difference between a "fixed" Vishera and a tuned Zambezi won't be that massive after the "Zambezi Stack Special" configuration.

http://imageshack.us/a/img526/3776/k7ez.jpg

Quote:

---

Originally Posted by The Stilt

Zambezi is significantly faster than Vishera in SuperPI by default

---

You surely mean it the other way around, dont you?

Quote:

---

Originally Posted by Opteron146

You surely mean it the other way around, dont you?

---

No.

Zambezi is faster than Vishera by:

SuperPI 1M: 4.84%
SuperPI 8M: 11.93%
SuperPI 32M: 14.61%

Quote:

---

Originally Posted by The Stilt

After some research I noticed that these registers do not respond on Zambezi based CPUs.
Upon reading all of them return null values and crash the system unless a special method is used.
At first it appeared that these registers do not exist on Zambezi, however after digging a bit deeper I found indication that the registers are there... But for some reason AMD seem to have protected them with a ESI/EDI password on Zambezi.

---

did you try the old magic 0x9c5a203a/9C5A203A ? I wonder if Opteron cpus behave the same, or is that hidden x87 common for all AMD cpus.

As I stated on HWBOT - you are a magician :)

My wife's 8350 waits in anticipation of your hard work.
I'm very enthusiastic about this, and for amd at the moment.

Awesome research and dev! :clap:

So, it is friday today isn't it ;)

Bulldozer Conditioner R1.00B

The checksum (MD5) for the zip file is: 418522A93F241CF14EB1D775839AB083
If the checksum does not match the package has been tampered with = delete and re-download from another location.
The checksum can be calculated online if you don't have a suitable software on your computer.
http://onlinemd5.com/

There is not a single bit of malicious code either in the driver or the software itself.
If you are unsure, please check the contents with https://www.virustotal.com

Supported OS: Windows XP / Windows Vista / Windows 7 / Windows 8 (32 & 64-bit)

The x86 version works in both 32 & 64-bit operating systems, while the x64 version is 64-bit only.
The functionality itself is identical between the versions.

Known limitations: Up to 16 CUs (32 cores) supported at the moment. Support for 32CUs (64 cores) will be added in the next version.

Also the R1.00B (Beta) version does not contain the feature to patch the microcode block as I could not make it work stable enough.

The "Errata Fix" button will fix the major errata which can be patched without updating the microcode.
This feature should not be used as a permanent solution, the bios update should still be used as a primary method (updated AGESA + microcode).

Note: Enabling "Zambezi Stack Special (PD)" feature might cause undefined behavior, however each user should test it's functionality on their own. Some applications might indicate a minor retardation in performance, however SuperPI for example receives a nice boost.

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.

There are most certainly some bugs, so in case you come across one, please report them to this thread.
The experiences are very welcome also.

No it is time for the midsummer parties so I might be away for a day or two.
Depending on how epic the headache shall be ;)

Update on 06/22/2013: Bulldozer Conditioner R1.01B

First, thanks very much for sharing this with us. It's very interesting.

Some quick dirty tests on an FX 8320 @ 4Ghz, before I go to bed.

..Definatly an improvement in super pi, which despite it's irrelevance now as an overall perf metric is still amazing to see the effect of a simple register change.

It also shows how little AMD care about this bench, despite the odd website still persisting with it when reviewing against the competition. Perhaps AMD's PR should be more vocal about why their CPU's are so slow at this piece of software, because there's a surprising amount of pseudo-enthusiasts out there that still judge by it.

http://i1149.photobucket.com/albums/...ps3bf16e4b.png

http://i1149.photobucket.com/albums/...ps2572d329.png

I just test it with my FX-6300 ( at stock with Turbo Core Enable)
Running SuperPi mod 1.5 XS edition

Before the patching
1M takes around 24s~

and after the patch applied
1M takes 20s now

Really cool and great job! :up:

Awesome work Stilt :). I tried on my 750K Piledriver and indeed I get 2.5 seconds lower score :).
I tried some other (non-x87 dominated) workloads and difference is within margin of error. Whatever the limitation was doing is not affecting other commercial benchmarks and software as much as it affect super pi.
Congrats on beating Fam. 10h record too Stilt :up:

PS What I find amazing is that users on other ( "inteltech" forum ;)) already found "reasons" why this is "fail". Instead rooting for people like Stilt, they do opposite of this .Very sad. Thankfully that forum has turned into a niche for intel trolls and shills (mod section too). Here we can show real appreciation for your work.

I cant download it :(...I got only pop ups :-/. Can u help me? Thank you.

//edit//:now is OK, some link worked at my side:). Awesome, in 4M more than 30s better!

Has anyone tried using this with other applications yet? Photoshop/lightroom cinebanche, etc?

I don't know about you guys, but I hate waiting for downloads. I've mirrored the file here.

Many many many thanks to The Stilt for adding some Xtreme to Xtreme Systems for the first time in ages :up:

Thank you The Stilt, you have made such a great tool to the OC community!

I have tried with my A10-6800K, it gets 5 seconds lower on my rig.
http://i265.photobucket.com/albums/i...abled_nrac.png

http://i265.photobucket.com/albums/i...abled_nrac.png

Back again.

Some of the users have been asking why the "Errata Fix" feature doesn't work (i.e. "Fix required" stated even after the Fix button has been pressed). The feature itself is working fine, however I forgot to add a check in the GUI. Also some claims that the software is wrong when it states that the microcode is outdated has emerged.

So:

A small update: Bulldozer Conditioner R1.01B

Original package checksum (MD5): C3C4E3492B3FBFE1079AE5D57C25172B

Changes:

- Added a hardware flag to indicate that the errata has been fixed.
- Changed the way how the software is accessing the cores, the tasks are completed quicker than before
- An APU specific bug fixed
- Added information about the most recent microcode and AGESA versions under Info menu.
- Some small changes to the GUI

Works perfectly :)

Without
http://www.zaslike.com/files/ikf99nwkkiqtszbtctkr.jpg

With
http://www.zaslike.com/files/hgbi12ql3pxbmvpfmbo.jpg

I have the new version mirrored here, it's exactly the same file as The Stilt uploaded and the MD5 hash can be verified at OnlineMD5. No pop-ups, no adverts, no waiting :)

This is really great Stilt, amazing work! One thing I wanted to point out. I have an FX 8350 in an ASRock 990FX Extreme9 running BIOS 1.01 (which was pulled months back). When I opened your tool, it gave me the option to apply the ERRATA fix and said I needed to update my BIOS. Is it really possible that ASRock's BIOS doesn't contain this ERRATA fix? I know the BIOS sucks and is buggy, and they have failed to release even a single update for it, but this would really put me over the edge if it's true.

Quote:

---

Originally Posted by EnJoY

This is really great Stilt, amazing work! One thing I wanted to point out. I have an FX 8350 in an ASRock 990FX Extreme9 running BIOS 1.01 (which was pulled months back). When I opened your tool, it gave me the option to apply the ERRATA fix and said I needed to update my BIOS. Is it really possible that ASRock's BIOS doesn't contain this ERRATA fix? I know the BIOS sucks and is buggy, and they have failed to release even a single update for it, but this would really put me over the edge if it's true.

---

Checked both of the bioses (1.00 & 1.10) for ASRock 990FX Extreme9.
Both of the bioses are based on an old AGESA version (V1.2.9.0), while the official launch AGESA version for Vishera was V1.5.0.0.
Due the old AGESA version the microcodes are outdated too:

Zambezi (OR-B2) - Installed: 06000626 (01/04/2012), The most recent version: 0600063D (03/06/2013).
Vishera (OR-C0) - Installed: 06000817 (05/24/2012), The most recent version: 06000822 (01/03/2013).

Version 0600063D (OR-B2) contains 10 errata fixes, while the 06000822 (OR-C0) fixes 8.

in 32M its awesome boost, I tried with decent summer stable OC profile...

http://i.imgur.com/A7hvjS1.png


more than4m 30s better result!!!! Woow. I think, 32M with LN2 could be quickly fun now with Vishera, maybe around 10minutes only.
http://i.imgur.com/LpTTuY3.png

Many many thanks, this is much appreciated and something I didn't even dream about!

This goes into AMD Hall of Fame I wonder what will be the response from both the community and AMD engineers :)

Quote:

---

Originally Posted by Oese

I wonder what will be the response from both the community and AMD engineers :)

---

They better be ashamed...

I wonder if it would be possible to mod these kinda fixes into bios like they do with SLIC tables and SLI certs (if you dont know what those are, head over to mydigitallife.info and read the bios forums)

Quote:

---

Originally Posted by The Stilt

Checked both of the bioses (1.00 & 1.10) for ASRock 990FX Extreme9.
Both of the bioses are based on an old AGESA version (V1.2.9.0), while the official launch AGESA version for Vishera was V1.5.0.0.
Due the old AGESA version the microcodes are outdated too:

Zambezi (OR-B2) - Installed: 06000626 (01/04/2012), The most recent version: 0600063D (03/06/2013).
Vishera (OR-C0) - Installed: 06000817 (05/24/2012), The most recent version: 06000822 (01/03/2013).

Version 0600063D (OR-B2) contains 10 errata fixes, while the 06000822 (OR-C0) fixes 8.

---

Wow, ASRock is terrible. Is this at all normal for a 990FX board to be using such an outdated AGESA? Thanks for your time.

Quote:

---

Originally Posted by EnJoY

Wow, ASRock is terrible. Is this at all normal for a 990FX board to be using such an outdated AGESA? Thanks for your time.

---

kinda wondering if the asrock 990fx extreme4 has the same outdated AGESA....used a few for friends builds......they clock damn well.....

if anybody knows please tell me.

Quote:

---

Originally Posted by EnJoY

Wow, ASRock is terrible. Is this at all normal for a 990FX board to be using such an outdated AGESA? Thanks for your time.

---

Quote:

---

Originally Posted by AzureSky

kinda wondering if the asrock 990fx extreme4 has the same outdated AGESA....used a few for friends builds......they clock damn well.....

if anybody knows please tell me.

---

This is for 970-990 chipset series motherboards only (althought some of the ASUS lower end models managed to slip in too).

http://imageshack.us/a/img823/86/lhdi.jpg

Zambezi microcodes marked with red > 06000629 still have the Valve CEG fault present.

Dammm That looks awe full. So much outdated or even worse :'(
I wonder if the Intel platforms have similar problems.

Strange that higher revision Gigabyte UD3 boards would revert back to older AGESA code than the older revision board.

Mhm i get an error "cannot initialize driver" on Sabertooth 990 FX R1.0 1604 Bios.

Anyone has a clue?

Quote:

---

Originally Posted by Oese

Mhm i get an error "cannot initialize driver" on Sabertooth 990 FX R1.0 1604 Bios.

Anyone has a clue?

---

Run as Admin.

Quote:

---

Originally Posted by EniGmA1987

Strange that higher revision Gigabyte UD3 boards would revert back to older AGESA code than the older revision board.

---

Check the compile date of the bioses.

Quote:

---

Originally Posted by The Stilt

Run as Admin.

---

Ouch! Works perfectly.... My Bad :)

-16 % in SPI 1M

Quote:

---

Originally Posted by The Stilt

This is for 970-990 chipset series motherboards only (althought some of the ASUS lower end models managed to slip in too).

Zambezi microcodes marked with red > 06000629 still have the Valve CEG fault present.

---

Thanks again for this. Looks like I shouldn't have gambled with ASRock.

Threw mine in here also. I ran each run without patch (the top Super PI) and with the patch (the bottom one). Very cool update. THis was with my 24/7 5ghz vishera. My chip uses only 1.475v to get the 5ghz and it shaved off 4 minutes from the 32m, so I am gonna play with the higher clocks it can do. Will throw some updates in here shortly. Good job STILT. :clap:

http://imageshack.us/a/img21/9798/gd5d.png

Here is the updated with Vishera at 5200mhz. Broke 15mins on 32m finally. LOL. If this improves performance on other programs that might have some similar code to super PI that would be nice. I read some said PhysX.

http://imageshack.us/a/img802/6751/gvo7.png

are we not able to manually update agesa code in bios as we used to in the past?

Quote:

---

Originally Posted by Ace123

are we not able to manually update agesa code in bios as we used to in the past?

---

As far as I know, nobody has ever done it successfully.
You would need to have access to the source code of the bios (vendor / model specific) project.

Quote:

---

Originally Posted by EnJoY

Thanks again for this. Looks like I shouldn't have gambled with ASRock.

---

I know this is OT, but I've been playing with ASRock boards myself lately... :rolleyes:
The specs and hardware look good, but the bios support has been questionable to say the least!
I bought a 990FX EX9 and was pretty disappointed with it. Bios support is seriously lacking, and the fact that they haven't even bothered to update the AGESA code is pititful.
It's pretty sad when you buy a companies top of the line board and there hasn't been a decent (lasting) bios update in six months... :shakes:
You can get decent clocks from the EX9, but it takes a lot of effort, and winds up being a random luck of the draw setting that makes no real sense to a decent overclocker. ...
That being said, the bios does fine at close to stock. Guess I need to put together a rig for Craigslist and get rid of this board. :(

For whatever reason (MicoCenter Combo deal?), I went with ASRock once again and grabbed the 6600K/ASRock EX6 (FM2) board.
I have to admit that it's heads above the EX9, and at least there have been a couple bios updates that have stuck and were actually usefull... :p:

Maybe ASRock is short on bios talent and they're directing it all towards FM2. Reguardless, I'd recommend the EX6, but steer folks away from the EX9!

I also agree that on current Motherboards, the most limiting factor are BIOSes that are missing features or have them badly implemented. You have examples like this, and this, of what issues are present when BIOS aren't fully compliant with specifications. Manufacturers usually don't go back to fix BIOS-related issues, even if from the Hardware side the Motherboard is perfect. This sometimes leaves you with non functional features (AMD-Vi for IOMMU virtualization comes to mind) because the BIOS developers seems to be ridiculous lazy. This include even if AMD wants to patch this via microcode, even if earlier AM3+ Motherboards could work with it, I doubt many will receive BIOS upgrades to do so.
How I would love that Coreboot could become more accessible to get rid of that propietary code crap...


Now, for some offtopic...

@ The Stilt
How in-depth is possible to analyze a BIOS BIN/ROM file with automatic tools and none to little knowledge? I suppose that at least someone must be able to easily retrieve AGESA version from a BIOS file to make the table you did there in a timely manner. Doubt someone could physically test THAT many Motherboards just for that purpose.
I'm looking for creative ways to be able to check if a Motherboard has proper AMD-Vi support or not by checking if it has a ACPI IVRS table (Or ACPI DMAR for Intel VT-d, for that matter), however, I have no idea of how exactly it should be inside a BIOS file to know what I should be looking for (Besides that I should also uncompress the BIOS modules first, I suppose). The idea is that anyone interesed in this feature for virtualization, would be able to discard Motherboards that don't have it functional before purchase by checking the BIOS for that table and at least some insight if the values retrieved seems to be valid.
Yep, absolutely non-related to x87, but its worth a shot.

I wonder if there are any other than SuperPI applications that got improvement?

Another question, does the older BIOS AGESA microcode impact performance, or it is x87 only?

A small update: Bulldozer Conditioner R1.02B

Original package checksum (MD5): BCC929498EF1B01B7F99B8F2DA805F46

Bulldozer Conditioner R1.02B

Changes:

- Enhanced the NRAC fix
- Added a UAC prompt (admin rights) for Windows Vista / 7 & 8.
- Updated the AGESA version info

The enhanced fix included in BDC R1.02B is around 10 seconds faster in SuperPI 32M than the one in R1.00 / R1.01 versions ;)

oh man! Im so proud and happy for you. I thought, after Chew* there be no one at right place and you came to us :).

Mirrored :up: http://flyingsuicide.net/wp-content/...BDC_R1.02B.zip

Quote:

---

Originally Posted by The Stilt

A small update: Bulldozer Conditioner R1.02B
...
The enhanced fix included in BDC R1.02B is around 10 seconds faster in SuperPI 32M than the one in R1.00 / R1.01 versions ;)

---

Awesome! :D

Man impressive, how does a guy even figure this out.

Quote:

---

Originally Posted by FlanK3r

oh man! Im so proud and happy for you. I thought, after Chew* there be no one at right place and you came to us :).

---

I for one welcome our new Overlord!

I request asrock tsd to update agesa version and vishera & zambezi ucode.
and now they checking that request.
If any update, they will update to website.

good :)

Quote:

---

Originally Posted by V-FrIeNd

I request asrock tsd to update agesa version and vishera & zambezi ucode.
and now they checking that request.
If any update, they will update to website.

---

Awesome! Nice work, thanks for taking the time.

Thanks a lot The Stilt. Highly appreciated :up:

why is this not stickied?

Is anyone else having trouble running it? I always get an error on startup that says "The driver failed to initialize!"

Quote:

---

Originally Posted by Particle

Is anyone else having trouble running it? I always get an error on startup that says "The driver failed to initialize!"

---

It must be run as admin.
R1.02 should prompt for priviledges, unless you have disabled the messages of course.

I had been trying to run it as an administrator to no avail, but in the end it turned out being that it could not be successfully ran from a mapped network share. It had to reside on my local disk. Once there, it ran just fine.

Why my Zambezi FX 8120 can't disable NRAC blocking :eek:
whether this function only for vishera & richland (gen2) ?

fx8120, asrock 990fx fatal1ty agesa V1.5.0.0 bios updated.

http://imageshack.us/scaled/landing/547/s25u.jpg

edit:
ok I see #35 O_o''

Quote:

---

Originally Posted by Daveburt714

Maybe ASRock is short on bios talent and they're directing it all towards FM2. Reguardless, I'd recommend the EX6, but steer folks away from the EX9!

---

Managed to persuade Asrock to patch up new BIOS betas with updated AGESA 1.5 codes, hoping to test them soon. :)

@Daveburt714 (and other 990FX Extreme9 guys), think you may enjoy tinkering with this updated beta L1.23A for your mobo. I have used it for playing with the FX-9590 sample the past few days, overall it's very usable altho' still slightly buggy.

http://ulozto.net/xd9AxM51/990fx9-123a-rar
pw - YMMV

Enjoy! :)

Quote:

---

Originally Posted by MacClipper

@Daveburt714 (and other 990FX Extreme9 guys), think you may enjoy tinkering with this updated beta L1.23A for your mobo. I have used it for playing with the FX-9590 sample the past few days, overall it's very usable altho' still slightly buggy.

http://ulozto.net/xd9AxM51/990fx9-123a-rar
pw - YMMV

Enjoy! :)

---

Awesome, great work getting a response out of them! I'll be flashing this tonight. Any other changes to this to be aware of other than updated AGESA?

hey EnJoY, I am actually waiting for you guys to tell me more cos I haven't been messing much with the Extreme9 myself till lately with the FX-9590 sample.

We really have to thank The Stilt for his superb expose of the state of Asrock BIOS, got them moving a bit faster after that one singular post. :D

@Daveburt714 (and other 990FX Extreme9 guys), a new final P1.30 has been released a few days ago at the official Asrock sites so go get it.


HTH

P1.30 is still crap. Still has outdated AGESA. Flashing the beta now.


Edit: Beta has been flashed. Latest AGESA confirmed! No time for doing any testing now, but I'll see if it improves stability later.

Info from my contact, so far only beta BIOS releases contain the updated AGESA so if you are keen try this newer 1.30A beta instead
http://ulozto.net/xU4yAXW4/990fx9-130a-rar

HTH

Quote:

---

Originally Posted by MacClipper

Info from my contact, so far only beta BIOS releases contain the updated AGESA so if you are keen try this newer 1.30A beta instead
http://ulozto.net/xU4yAXW4/990fx9-130a-rar

HTH

---

Nice, I'll flash this when I am home. So far the system definitely seems more stable, and I'm not getting the stupid sleep bugs I was getting before (despite having ALL power management disabled).

Played with it over a day, it's less buggy than the previous beta and this one overclocks via Offset voltages.

Have fun. :)

now somebody just needs to get asus to update the bios for my sabertooth's(2 rev1's) with latest AGESA and i will be happy :P

Quote:

---

Originally Posted by MacClipper

Info from my contact, so far only beta BIOS releases contain the updated AGESA so if you are keen try this newer 1.30A beta instead
http://ulozto.net/xU4yAXW4/990fx9-130a-rar

HTH

---

Thanks Mac,

The RAR file for 1.30A seems to want a password to un-pack it... Could you share that? (PM is OK if you don't want it in the wild)
I really haven't messed with that board much, since I didn't need it. I've got a little free time now though, so I thought I'd give it another shot. ;)