AMD "Piledriver" refresh of Zambezi - info, speculations, test, fans

[TESKATLIPOKA]

demonkevy666 actually its much worse at least in AIda64.
AMD Phenom II X4 980 BE vs FX4100
L1 cache
read 118,658MB vs 121066MB
write 59416MB vs 21230MB
copy 79171MB vs 42420MB

http://pctuning.tyden.cz/ilustrace3/...0/cachemem.png
http://pctuning.tyden.cz/ilustrace3/...4/cachemem.png

[mrcmtl]

A half clocked L2, if true, would explain the high L2 latencies in Aida64. Even my 1.5Ghz Llano has lower L2 latencies with it been around 4.0ns while 3.6Ghz FX gets above 5.0ns.

Is a say 3Ghz fully clocked FX slower than a 3.6Ghz FX with half L2 clock...

[TESKATLIPOKA]

If L2 was half-clocked wouldn't it mean that not just the latency is doubled but also the memory throughput is halved? What I see is that the L2 in BD has comparable memory throughput to Deneb.

[TESKATLIPOKA]

Some interesting slides from domaninhaber video, my thanks goes to del42sa from pctuning.cz forum
http://img7.rajce.idnes.cz/d0703/5/5...es/Trinity.jpg
http://img7.rajce.idnes.cz/d0703/5/5...ty_3D_mark.jpg
http://img7.rajce.idnes.cz/d0703/5/5...ty_PC_Mark.jpg
http://img7.rajce.idnes.cz/d0703/5/5...ty_Compute.jpg
http://img7.rajce.idnes.cz/d0703/5/5...al_graphic.jpg
http://img7.rajce.idnes.cz/d0703/5/5...al_graphic.jpg
Honestly I don't know what to think, if you look at the IGP performance in FLOPs
Llano 415 GFLOPs
Trinity 715 GFLOPs
Llano theoretical numbers
5SIMD * 16ALU*5SP*2*600MHz=480GFLOPs
415GFLOPs/480GFLOPs = 86.5%
and now Trinity
715/0.865=827GFLOPs
That should mean 10SIMDs VLIW4 at 646Mhz.
Thats impossible, they wouldn't be able to feed it with data, ~half of the TDP would be just for IGP and the performance in 3D mark doesn't match either. It wouldn't be stronger by just 35% but rather 1.8-2x. Even die size would be bigger compared to Llano's, maybe ~270-280mm2.

edit: my mistake, the FLOPs should be CPU+IGP but even so It doesn't match by a long shot.

P.S. Undone was faster

[undone]

Some interesting slides from domaninhaber video, my thanks goes to del42sa from pctuning.cz forum
http://img7.rajce.idnes.cz/d0703/5/5...es/Trinity.jpg
http://img7.rajce.idnes.cz/d0703/5/5...ty_3D_mark.jpg
http://img7.rajce.idnes.cz/d0703/5/5...ty_PC_Mark.jpg
http://img7.rajce.idnes.cz/d0703/5/5...ty_Compute.jpg
http://img7.rajce.idnes.cz/d0703/5/5...al_graphic.jpg
http://img7.rajce.idnes.cz/d0703/5/5...al_graphic.jpg
Honestly I don't know what to think, if you look at the IGP performance in FLOPs
Llano 415 GFLOPs
Trinity 715 GFLOPs
Llano theoretical numbers
5SIMD * 16ALU*5SP*2*600MHz=480GFLOPs
415GFLOPs/480GFLOPs = 86.5%
and now Trinity
715/0.865=827GFLOPs
That should mean 10SIMDs VLIW4 at 646Mhz.
Thats impossible, they wouldn't be able to feed it with data, ~half of the TDP would be just for IGP and the performance in 3D mark doesn't match either. It wouldn't be stronger by just 35% but rather 1.8-2x. Even die size would be bigger compared to Llano's, maybe ~270-280mm2.

edit: my mistake, the FLOPs should be CPU+IGP but even so It doesn't match by a long shot.

P.S. Undone was faster

I think, these scores are plausible, unless someone tell me these result are unofficial and are given by some NDAers/testers.

[TESKATLIPOKA]

undone Most of the GFLOPs should be coming from the IGP and the increase doesn't match with +35% in 3D mark. If the CTP was ~550-590 then I don't have a problem.

[informal]

Scores are from AMD document... Someone broke the NDA ,again.
They are plausible,the GPU part will rock. But we all knew this already. The question is how much of an upgrade will PD be on desktop. The pcmark vantage scores look good but I have already found some reviews of A8 3850 in which it gets 7500+pts in this benchmark,so there are many unknowns such as test setup,bios/drivers etc. If retail Trinity gets propertionally better score versus 3850 in real reviews then it will be good. IMO it needs to be faster than FX4xxx series (which is not that hard of a task ).

[FlanK3r]

IGPU looks very good, it will be great for most of games up to 1680x1050 with high resolution witout AA

[informal]

Oh I forgot that someone asked about memory BW. Don't forget that BD has radically improved memory controller versus anything K10(30% due to pure uarchitectural improvements and rest is dram clock increase). I expect they ported some Llano stuff to it in order to service both parts of the die(like Onion and Garlic).

[Smartidiot89]

The scores seems about right (especially the GFLOPS values). It has been known since the launch of Llano that GFLOPS increase would be 50% and in total above 800 for the whole APU (which includes the CPU cores). I was thinking more in the lines of 8 VLIW4 SIMDs @ 700 MHz + CPU to make up for it.

Like Informal said the memory controller will be a new one, and Trinity will support memory clocks @ 2133 MHz.

[TESKATLIPOKA]

Smartidiot89 What we see is a 72% increase in combined FLOPs and the thing is such an IGP won't give you just 35% increase in performance as shown in 3D mark but should give >+60%.
The 35% increase should mean the IGP is just
6 VliW4 SIMDs @700Mhz(+25%SIMD and +17% frequency) at best.

edit: If I think about it, both systems were using just 1866Mhz memories, so if using 2133Mhz would give the same improvement as the difference in speed then it would be 15%, so in total it would mean +50% and that is acceptable, but then there is a question why use only 1866Mhz memories in the test for Trinity.

[mrcmtl]

If L2 was half-clocked wouldn't it mean that not just the latency is doubled but also the memory throughput is halved? What I see is that the L2 in BD has comparable memory throughput to Deneb.

L2 read is 2x slower, L2 write is 50% slower and L2 copy is faster for BD compared to K10.

[informal]

L2 is almost on par with L3 cache in BD (on par being almost as slow as)... That's what aida reports at least. If it's true (half clocking) then they can try to remedy this if/when GloFo can reach a level of process maturity to allow this change. L2 cache is very very important for client workloads.

[TESKATLIPOKA]

mrcmtl doesn't look that way, only write is somewhat slower
http://pctuning.tyden.cz/ilustrace3/...DFX/aida64.png
http://pctuning.tyden.cz/ilustrace3/...0/cachemem.png

http://i55.tinypic.com/jjs221.jpg
http://www.xtremesystems.org/forums/...3&d=1318067554

informal where is L2 on par with L3? It would be nice if L2 was half clocked but that's not the case.

[informal]

No I didn't say it is half clocked.It's just what dresdenboy speculated based on his research. It can be that L2 is just that slow by design,who knows.

[demonkevy666]

L2 is almost on par with L3 cache in BD (on par being almost as slow as)... That's what aida reports at least. If it's true (half clocking) then they can try to remedy this if/when GloFo can reach a level of process maturity to allow this change. L2 cache is very very important for client workloads.

then HTT clock would show higher gains vs multiplier which is some what true.

[mrcmtl]

mrcmtl doesn't look that way, only write is somewhat slower
http://pctuning.tyden.cz/ilustrace3/...DFX/aida64.png
http://pctuning.tyden.cz/ilustrace3/...0/cachemem.png

http://i55.tinypic.com/jjs221.jpg
http://www.xtremesystems.org/forums/...3&d=1318067554

informal where is L2 on par with L3? It would be nice if L2 was half clocked but that's not the case.

hmm, my bad then. My source had an incredibly low L2 read for some reason. But anyhow, the L2 latencies are really problematic...

http://realworldtech.com/beta/forums...23488&roomid=2

[Oliverda]

Umhh...you're looking at the end result ( CPU performance ) and blaming only one factor that contributes to that performance : process.
Alongside process, performance and performance/watt is dependent on architecture and circuit design.

I really doubt BD is perfect uarch and implementation wise and only the process is to blame. If we would have someone from GF here, I'm sure he'd say not so nice things about AMD competence in CPU design.

Agree or not but the main problem is the process tech. Nobody said that BD is perfect uarch anyway.

If you don't believe it then just take a look at Llano CPU cores. Despite of the 32nm process it can't reach the previous very similar uarch clocks even with overclocking.



At this moment the scaling of 32nm is worse than the latest 45nm one.

[FlanK3r]

so...problem of GF...

[informal]

Bulldozer didn't turn out as good as AMD have hoped AND GlofFo's process was nowhere near as good as AMD had hoped. "Perfect storm" for a worse than expected desktop performance (although server is certainly affected too,but not as much as desktop).

[BeepBeep2]

With Llano at 2.7 and 2.9 at VID's up to 1.4v there's no suprise that GloFo's 32nm is trash. They could have produced the same chips on their 45nm process with 1.15-1.25v considering they were producing Deneb up to 3.7 Ghz under 1.4v VID.
BD for some reason is less efficient performance wise, especially on the server side, had they added 300 Mhz to Magny Cours over 12 cores and a few hundred turbo they would have had a CPU that outperforms the 16 core by a significant margin.

"Stars" is a very efficient core when it comes to mm^2 to performance, on the level of Lynnfield at 45nm process. BD was quite a step backward from that, not sure how much we can blame the manufacturing process for that.

[freeloader]

The engiqueers at AMD really borked the design of anything Bulldozer related, server or desktop. It's a horrible chip. They have a chance to redeem themselves with Trinity, but that's not going to happen in their work environment at AMD.

[sdlvx]

The engiqueers at AMD really borked the design of anything Bulldozer related, server or desktop. It's a horrible chip. They have a chance to redeem themselves with Trinity, but that's not going to happen in their work environment at AMD.

Come on man lets keep this technical, instead of a bunch of rumors that showed up on a blog about how everything is automated and AMD is doomed because their chips use up 20% more space and lose 20% more performance. If you can show me the places where BD's die space can be reduced by 20% and where performance can be increased by 20%, please show me.

There's plenty of solid proof that the GloFo 32nm process is borked, primarily how there's no clock or VID difference between 32nm BD and 45nm Stars, while Stars was designed for efficiency and BD was designed for high clocks and there's a tradeoff between both.

Compare TSMC's 55nm and 40nm process with 4870 and 4770 GPUs. http://www.gpureview.com/show_cards....=564&card2=612 4770 is at the same clock, yet uses almost half as much power. These are the kinds of things we should be seeing with GloFo 32nm, but we're not. I doubt BD is that messed up where it would use twice as much power as Stars. I'm not saying it should use half, they are different archs and 4770 and 4870 are the same, but for power consumption to go up pretty much shows that there's serious issues with GloFo 32nm.

Because of this, I don't see 32nm Stars being much better than BD. Explain to me why a leaky and lossy manufacturing process is going to care about what architecture it's running on. From trinity it looks like BD is good when it's not leaking and running away with power consumption at higher volts.

[Oliverda]

The engiqueers at AMD really borked the design of anything Bulldozer related, server or desktop. It's a horrible chip. They have a chance to redeem themselves with Trinity, but that's not going to happen in their work environment at AMD.

Is that all what you can tell?

An uarch can fail or win on the process tech. Just try imagine if the top quad core SB would have ~2.5 GHz base clock with 130 watt TDP.

[undone]

IMO, Llano should be up to 3.5Ghz if everything went well, but it didn't. If trinity could be up to 4.5Ghz(3.8-4.1Ghz for known ES) and has some other fix with mass production silicon, I bet it could do well.