Quote Originally Posted by cadaveca View Post
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?

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