The Bulldozer Review: AMD FX-8150 Tested
by Anand Lal Shimpi on October 12, 2011 1:27 AM ESTGaming Performance
AMD clearly states in its reviewer's guide that CPU bound gaming performance isn't going to be a strong point of the FX architecture, likely due to its poor single threaded performance. However it is useful to look at both CPU and GPU bound scenarios to paint an accurate picture of how well a CPU handles game workloads, as well as what sort of performance you can expect in present day titles.
Civilization V
Civ V's lateGameView benchmark presents us with two separate scores: average frame rate for the entire test as well as a no-render score that only looks at CPU performance.
While we're GPU bound in the full render score, AMD's platform appears to have a bit of an advantage here. We've seen this in the past where one platform will hold an advantage over another in a GPU bound scenario and it's always tough to explain. Within each family however there is no advantage to a faster CPU, everything is just GPU bound.
Looking at the no render score, the CPU standings are pretty much as we'd expect. The FX-8150 is thankfully a bit faster than its predecessors, but it still falls behind Sandy Bridge.
Crysis: Warhead
In CPU bound environments in Crysis Warhead, the FX-8150 is actually slower than the old Phenom II. Sandy Bridge continues to be far ahead.
Dawn of War II
We see similar results under Dawn of War II. Lightly threaded performance is simply not a strength of AMD's FX series, and as a result even the old Phenom II X6 pulls ahead.
DiRT 3
We ran two DiRT 3 benchmarks to get an idea for CPU bound and GPU bound performance. First the CPU bound settings:
The FX-8150 doesn't do so well here, again falling behind the Phenom IIs. Under more real world GPU bound settings however, Bulldozer looks just fine:
Dragon Age
Dragon Age is another CPU bound title, here the FX-8150 falls behind once again.
Metro 2033
Metro 2033 is pretty rough even at lower resolutions, but with more of a GPU bottleneck the FX-8150 equals the performance of the 2500K:
Rage vt_benchmark
While id's long awaited Rage title doesn't exactly have the best benchmarking abilities, there is one unique aspect of the game that we can test: Megatexture. Megatexture works by dynamically taking texture data from disk and constructing texture tiles for the engine to use, a major component for allowing id's developers to uniquely texture the game world. However because of the heavy use of unique textures (id says the original game assets are over 1TB), id needed to get creative on compressing the game's textures to make them fit within the roughly 20GB the game was allotted.
The result is that Rage doesn't store textures in a GPU-usable format such as DXTC/S3TC, instead storing them in an even more compressed format (JPEG XR) as S3TC maxes out at a 6:1 compression ratio. As a consequence whenever you load a texture, Rage needs to transcode the texture from its storage codec to S3TC on the fly. This is a constant process throughout the entire game and this transcoding is a significant burden on the CPU.
The Benchmark: vt_benchmark flushes the transcoded texture cache and then times how long it takes to transcode all the textures needed for the current scene, from 1 thread to X threads. Thus when you run vt_benchmark 8, for example, it will benchmark from 1 to 8 threads (the default appears to depend on the CPU you have). Since transcoding is done by the CPU this is a pure CPU benchmark. I present the best case transcode time at the maximum number of concurrent threads each CPU can handle:
The FX-8150 does very well here, but so does the Phenom II X6 1100T. Both are faster than Intel's 2500K, but not quite as good as the 2600K. If you want to see how performance scales with thread count, check out the chart below:
Starcraft 2
Starcraft 2 has traditionally done very well on Intel architectures and Bulldozer is no exception to that rule.
World of Warcraft
Facebook
Twitter
RSS
430 Comments
View All Comments
nofumble62 - Thursday, October 13, 2011 - link
Crappy building block will mean crappy building.richaron - Friday, October 14, 2011 - link
At first I was pissed off by being strung along for this pile of tripe. After sleeping on it, I am not completely giving up on this SERVER CHIP:1) FX is a performance moniker, scratch stupid amount of cache & crank clock
2) I'm sure these numbties can get single thread up to thuban levels
3) Patch windows scheduler ffs
Fix those (relatively simple) things & it will kick ass. But it means most enthusiasts wont be spending money on AMD for a while yet.
7Enigma - Friday, October 14, 2011 - link
Biggest problem for a server chip is the load power levels. It just doesn't compete on that benchmark and one in which is VERY important for a server environment from a cost/heat standpoint.Let's hope that's just a crappy leaky chip due to manufacturing but it's to early to tell.
richaron - Friday, October 14, 2011 - link
I've worked in a 'server environment'. of course power consumption is an issue. at the lower clock speeds & considering multithread performance, this is already a good/great contender. virtual servers & scientific computing this is already a winnar.with a few (hardware & software) tweaks it could be a GREAT pc chip in the long term.
ryansh - Friday, October 14, 2011 - link
Anyone have a BETA copy of WIN8 to see if BD's performance increases like AMD says it will.silverblue - Friday, October 14, 2011 - link
There's benchmarks here and there but nothing to say it'll improve performance more than 10% across the board. In any case, the competition also benefits from Windows 8, so it's still not a sign of AMD closing any sort of gap in a tangible fashion.Pipperox - Friday, October 14, 2011 - link
But Bulldozer is different.Windows 7 scheduler does not have a clue about its "modules" and "cores".
So for example it may find it perfectly legit to schedule 2 FP intensive threads to the same module.
Instead this will result in reduced performance on Bulldozer.
Also one may want to schedule two integer threads which share the same memory space to the same module, instead of 2 different modules.
This way the two threads can share the same L2 cache, instead of having to go to the L3 which would increase latency.
All of the above does not apply to Thuban; to a lesser degree it applies to Sandy Bridge, but Windows 7 scheduler is already aware of Sandy Bridge's architecture.
nirmv - Saturday, October 15, 2011 - link
Pipperox, It's not different than Intel's Hyper Threading.Pipperox - Sunday, October 16, 2011 - link
It is, although they're similar concepts.Let's make an example: you have 2 integer threads working on the same address space (for example two parallel threads working in the same process).
All cores are idle.
What is the best scheduling for a Hyperthreading cpu?
You schedule each thread to a different core, so that they can enjoy full execution resources.
What is best on Bulldozer?
You schedule them to the SAME module.
This because the execution resources are split in a BD module, so there would be no advantage to schedule the threads to different modules.
HOWEVER if the 2 threads are on the same module, they can share the L2 cache instead of the L3 cache on BD, so they enjoy lower memory latency and higher bandwidth.
There are cases where the above is not true, of course.
But my example shows that optimal scheduling for Hyperthreading can be SUB-optimal on Bulldozer.
Hence the need for a Bulldozer-aware scheduler in Windows 8.
Regs - Friday, October 14, 2011 - link
AMD needs a 40-50% performance gain and they're not going to see it using windows 8. What AMD needs is...actually I have no clue what the need. I've never been so dumbfounded about a product that makes no sense or has any position in the market.