Overclock.net › Forums › Industry News › Rumors and Unconfirmed Articles › [Various] AMD's Zen To Have 10 Pipelines Per Core - Details Leaked In Patch (Updated)
New Posts  All Forums:Forum Nav:

[Various] AMD's Zen To Have 10 Pipelines Per Core - Details Leaked In Patch (Updated) - Page 17

post #161 of 758
Quote:
Originally Posted by Robenger View Post

What a surprise to find you here.
Ditto
2010rig
(14 items)
 
Galaxy S3
(8 items)
 
 
CPUMotherboardGraphicsRAM
X5660 @ 4.5  ASUS P6X58D-E 980TI? 12GB OCZ Platinum - 7-7-7-21 
Hard DriveCoolingOSMonitor
1 80GB SSD x25m - 3TB F3 + F4 NH-D14 Windows 7 Ultimate LG 47LH55 
KeyboardPowerCaseMouse
Natural Wireless Keyboard Corsair 750HX CM 690 II Advanced MX 518 
CPUGraphicsRAMHard Drive
Snapdragon S4 Dual core 1500mhz Adreno 225 Samsung 2GB 16GB Onboard Flash 
OSMonitorPowerCase
Android 4.4.2 - CM11 4.8" AMOLED 1280x720 2100 mAh battery Otterbox Defender 
  hide details  
Reply
2010rig
(14 items)
 
Galaxy S3
(8 items)
 
 
CPUMotherboardGraphicsRAM
X5660 @ 4.5  ASUS P6X58D-E 980TI? 12GB OCZ Platinum - 7-7-7-21 
Hard DriveCoolingOSMonitor
1 80GB SSD x25m - 3TB F3 + F4 NH-D14 Windows 7 Ultimate LG 47LH55 
KeyboardPowerCaseMouse
Natural Wireless Keyboard Corsair 750HX CM 690 II Advanced MX 518 
CPUGraphicsRAMHard Drive
Snapdragon S4 Dual core 1500mhz Adreno 225 Samsung 2GB 16GB Onboard Flash 
OSMonitorPowerCase
Android 4.4.2 - CM11 4.8" AMOLED 1280x720 2100 mAh battery Otterbox Defender 
  hide details  
Reply
post #162 of 758
Quote:
Originally Posted by Dom-inator View Post

Broadwell does so well in CPU intensive games like Arma. Some eDRAM / L4 cache please AMD? biggrin.gif
Zen APUs with HBM2 should be appearing sometime in 2017.
post #163 of 758
Quote:
Originally Posted by Disharmonic View Post

Zen APUs with HBM2 should be appearing sometime in 2017.

so long as its 512MB minimum on-die cache, or ideally 1GB.

with that large of a cache, it'd be sufficient for typical workloads that're fit for IGPs.
considering the IGP isn't sufficient for high-resolutions, its just extra costs to stuff it with anything larger.
it'd be a miracle for an IGP to manage 60fps on 1080P Ultra x8 AA settings.
Edited by epic1337 - 10/8/15 at 1:35pm
post #164 of 758
Once the memory bandwidth limitations have been solved, the iGPU performance will ramp up rather quickly.
Currently there is absolutely no point in increasing the performance on the iGPU, since at least 25% of the current performance is already wasted by the bandwidth restriction. No conventional DRAM or compression technology can overcome the issue.

Until HBM2 is available to APU / SoCs it is game over for them.

I personally think that it is too early for HBM2 to appear in Raven Ridge (Zen based APU). The technology will be available at the time, however if it is available at reasonable cost is a whole another question. My guess is that it is not.
post #165 of 758
Quote:
Originally Posted by EniGma1987 View Post

I seem to remember reading quite a while ago that Zen was removing certain hardware blocks like MMX because it is used so little and there are other things that are more moderns and offer more performance. This is done to save die space and increase performance. IDK if it really is true that MMX is not used much at all anymore, but that's what the reasoning was.

They won't. The MMX unit is still there, didnt notice it was Zen. I mean why would you make your own "AMD"- like Zen pictures? Kinda feels like it's official, thats why I actually havent noticed in the first place because I thought it was Bulldozer orsomething.



The MMX units are used for integer calculations stuff like AES/SHA etc and much more than that, considering Zen will be a server platform it would be stupid dropping it. Space wont be really an issue especially with the massive IPC boost & 14/16nm (whatever it is) they won't need to use that many cores to compete with Intel's mainstream line, it's not that AMD needs to drop 20 cores just to get on par with a i5's MT performance. Not sure if you noticed but Intel cores are really big, I wouldn't be surprised a Skylake core @ 32nm being nearly bigger than a BD module.
post #166 of 758
Quote:
Originally Posted by The Stilt View Post

I feel like an idiot, but this must be corrected mad.gif
I made a rookie mistake with Carrizo while reconfiguring the power management for the tests.
Warning: Spoiler! (Click to show)
Carrizo requires some re-configuring in order to be able to run at static frequency.
While the power limits were configured correctly and all the power management features were fine (i.e. no throttling possible), I managed to screw up the frequency itself doh.gif

The frequency was configured correctly to 3.0GHz, however since I had disabled the power management in order to produce results at static frequency the new frequency was never actuated. When the power management is enabled manual actuation of the CorePLL is not required, since the power management will be changing the PLL FID several times per second. If the power management is disabled the new frequency (which in this case was changed from 3.4GHz to 3.0GHz) must be refreshed by hand. Otherwise the actual frequency won´t change. For the first three results I forgot to do this procedure, however for Cinebench R15 it was done because the system was rebooted prior running it rolleyessmileyanim.gif

Quote from BKDG: "The PstateId field must be updated to cause a new CpuFid value to take effect."

C-Ray V1.1 (Raytracer)
Compiler GCC 5.20 x86-64, CFlags = O3 & static
1600x1200 with 8 rays per pixel (15360000)

PD = 187155ms (82071.0pps) - 100.0%
SR = 184502ms (83251.1pps) - 101.438%
XV = 170368ms (90157.8pps) - 109.853%
HW = 116907ms (131386.5pps) - 160.089%

Euler3D (CFD)
Compiler GCC 5.20 x86-64, CFlags = O3 & static
NACA0012.097K air foil

PD = 177.076s (11.2946 IPS) - 100.0%
SR = 151.380s (13.2102 IPS) - 116.960%
XV = 135.674s (14.7412 IPS) - 130.515%
HW = 94.521s (21.1593 IPS) - 187.340%

X265 (Encoder)
Compiler GCC 5.20 x86-64 / YASM 1.30 (default flags)
Version 1.7+512

PD = 225.25s (1.57 fps) - 100.0%
SR = 213.97s (1.65 fps) - 105.1%
XV = 204.81s (1.72 fps) - 109.554%
HW = 117.12s (3.01 fps) - 191.720%

Cinebench R15

PD = 71pts - 100.0%
SR = 72pts - 101.408%
XV = 75pts - 105.634%
HW = 119pts - 167.606%
If you quoted the original results, please correct them in your posts.

Sorry guys frown.gif

You're still only using four benchmarks, and you're much more in line with my results than you were now.

My estimate it just at 64% improvement, while your older figures had it at 72%, your current ones put it at 59.44%.

Your real problem is that your particular selection of benchmarks heavily favors Haswell's improvements. You need to run some more benchmarks drunken.gif

My collection is spread around in too many spreadsheets to summarize right now (bed time), but I'll make a point to run a full suite of tests using the 4690k that should be coming in the next couple of weeks (hate building computers piecemeal for people, but when they don't have all the money... what's a loon to do?).

I will say, though, my Haswell score for CB15, equalized to 3GHz, is 123 vs your 119. My x265 and POVRay numbers don't seem to be compatible with yours at all.

Unadjust 4.4GHz Haswell

POVRay:1834
x265: 1.75

An i7 2600k (my current CPU) will do
POVRay: 1532
x265: 1.49

That said, I do have a spreadsheet with a range for Zen, and it bottoms out just above Sandy Bridge, and just breaks even with Haswell as the top, somewhere in the middle is quite likely.
post #167 of 758
Quote:
Originally Posted by looncraz View Post

You're still only using four benchmarks, and you're much more in line with my results than you were now.

My estimate it just at 64% improvement, while your older figures had it at 72%, your current ones put it at 59.44%.

Your real problem is that your particular selection of benchmarks heavily favors Haswell's improvements. You need to run some more benchmarks drunken.gif

My collection is spread around in too many spreadsheets to summarize right now (bed time), but I'll make a point to run a full suite of tests using the 4690k that should be coming in the next couple of weeks (hate building computers piecemeal for people, but when they don't have all the money... what's a loon to do?).

I will say, though, my Haswell score for CB15, equalized to 3GHz, is 123 vs your 119. My x265 and POVRay numbers don't seem to be compatible with yours at all.

Unadjust 4.4GHz Haswell

POVRay:1834
x265: 1.75

An i7 2600k (my current CPU) will do
POVRay: 1532
x265: 1.49

That said, I do have a spreadsheet with a range for Zen, and it bottoms out just above Sandy Bridge, and just breaks even with Haswell as the top, somewhere in the middle is quite likely.

By saying "your particular selection of benchmarks heavily favors Haswell's improvements" you of course mean that these benchmarks are floating point heavy instead of being integer heavy.

15h CPUs never had real issues with integer performance since they had sufficient resources built into them, which never was the case with FP.
It would be silly to use integer heavy workloads to predict the performance of Zen, since the improvement in integer performance won´t decide the fate of AMD. The floating point performance of Zen will. 15h CPUs are behind the competition in integer performance too, but the difference isn´t even remotely as massive as in floating point.
post #168 of 758
Quote:
Originally Posted by Faithh View Post

They won't. The MMX unit is still there, didnt notice it was Zen. I mean why would you make your own "AMD"- like Zen pictures? Kinda feels like it's official, thats why I actually havent noticed in the first place because I thought it was Bulldozer orsomething.



The MMX units are used for integer calculations stuff like AES/SHA etc and much more than that, considering Zen will be a server platform it would be stupid dropping it.

That image is made by wccf. It's incorrect, it shows only 4 integer pipelines and 256bit FMACs, which is wrong. MMX functions use the same pipelines as the fp functions. It's hard to say whether there is no MMX unit or whether it's sharing pipelines.
post #169 of 758
This is the supposed Zen, came out before actual reveal but showing the six integer pipelines lends it some credibility

AMD-Zen-Core-Block-Diagram.jpg



It may well be labeled as 256bit FMAc if AMD is planning on letting the 128bit units merge or allowing a 256bit unit to be split. Males sense so they can get better legacy FPU performance

AMD-Zen-Slide-2.jpg
This early slide even has the right L2 numbers and move to inclusive cache
Edited by LuckyStarV - 10/9/15 at 2:11am
Foot Warmer
(11 items)
 
  
CPUMotherboardGraphicsRAM
Intel i5 4670k @ 4.2ghz core/4ghz uncore MSI Z87 G45 Gaming Powercolor Radeon R9 280 OC 16GB G.Skill Ripjaws X 1866mhz 
Hard DriveHard DriveCoolingMonitor
2TB Seagate Barracuda 7200.14 128GB Adata SP920  Corsair H80i  LG 22EN33 
PowerCaseMouse
Corsair CX600v2.3 Antec 302 Zalman M200 
  hide details  
Reply
Foot Warmer
(11 items)
 
  
CPUMotherboardGraphicsRAM
Intel i5 4670k @ 4.2ghz core/4ghz uncore MSI Z87 G45 Gaming Powercolor Radeon R9 280 OC 16GB G.Skill Ripjaws X 1866mhz 
Hard DriveHard DriveCoolingMonitor
2TB Seagate Barracuda 7200.14 128GB Adata SP920  Corsair H80i  LG 22EN33 
PowerCaseMouse
Corsair CX600v2.3 Antec 302 Zalman M200 
  hide details  
Reply
post #170 of 758
Quote:
Originally Posted by LuckyStarV View Post

This is the supposed Zen, came out before actual reveal but showing the six integer pipelines lends it some credibility

AMD-Zen-Core-Block-Diagram.jpg



It may well be labeled as 256bit FMAc if AMD is planning on letting the 128bit units merge or allowing a 256bit unit to be split. Males sense so they can get better legacy FPU performance

That image was proven fake. It's not 2x256bit FMAC, because FMAC requires both FADD and FMUL to work. So since it's 2x128bit FADD and 2x128bit FMUL, that results in 2x128bit FMAC, which can fuse into 1x256bit FMAC.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Rumors and Unconfirmed Articles
Overclock.net › Forums › Industry News › Rumors and Unconfirmed Articles › [Various] AMD's Zen To Have 10 Pipelines Per Core - Details Leaked In Patch (Updated)