HKSpot - Powered by Discuz! Board

標題: [業界消息] Carrizo [打印本頁]

作者: Puff 時間: 2014-7-16 21:02 標題: Carrizo

http://www.computerbase.de/2014-07/amd-carrizo-mit-hdmi-2.0-und-voller-hsa-unterstuetzung/

同預期無差別除左L2縮水
就只係整合FCH版Kaveri + Full HSA support
製程發夢果陣話係28nmGF標準版 KV用既SHP係「定制版」
分別既緣由係話因為GF後黎搞左個盡量貼近台★電既28nm方便轉單既版本

[ 本帖最後由 Puff 於 2014-7-16 21:05 編輯 ]

作者: qcmadness 時間: 2014-7-16 21:03

聽住先

作者: Puff 時間: 2014-7-16 21:05

引用:

原帖由 qcmadness 於 2014-7-16 21:03 發表
聽住先

呢單料無 hype 喎

作者: qcmadness 時間: 2014-7-16 21:28

引用:

原帖由 Puff 於 2014-7-16 21:05 發表

呢單料無 hype 喎

唔會用TSMC啦

作者: Puff 時間: 2014-7-16 21:46

引用:

原帖由 qcmadness 於 2014-7-16 21:28 發表

唔會用TSMC啦

我係話用女朋友 28nm 標準製程
然後個製程俾係俾女朋友特登改到個 spec 同台★電相近方便轉單係方便人轉用女朋友
依家個 28SHP 發夢係話女朋友無數個舊版 28nm 之中其中一個黎

p.s. 1MB L2 縮水版希望L2 latency有大突破...

[ 本帖最後由 Puff 於 2014-7-16 21:50 編輯 ]

作者: qcmadness 時間: 2014-7-16 21:51

引用:

原帖由 Puff 於 2014-7-16 21:46 發表

我係話用女朋友 28nm 標準製程
然後個製程俾係俾女朋友特登改到個 spec 同台★電相近方便轉單係方便人轉用女朋友
依家個 28SHP 發夢係話女朋友無數個舊版 28nm 之中其中一個黎

p.s. 1MB L2 縮水版希望L2 ...

其實shared 1MB L2先應該係Bulldozer family optimal cache size

作者: Puff 時間: 2014-7-16 21:52

引用:

原帖由 qcmadness 於 2014-7-16 21:51 發表

其實shared 1MB L2先應該係Bulldozer family optimal cache size

IEEE paper 其實有提 1MB 版本 18-cycle load-use
但始終問題係 BD 無得救

作者: qcmadness 時間: 2014-7-16 21:53

引用:

原帖由 Puff 於 2014-7-16 21:52 發表

IEEE paper 其實有提 1MB 版本 18-cycle load-use
但始終問題係 BD 無得救

無得救還無得救

咁die size因為小一半L2 cache小10%, 講成本就已經差好遠

作者: Puff 時間: 2014-7-16 21:54

引用:

原帖由 qcmadness 於 2014-7-16 21:53 發表

無得救還無得救

咁die size因為小一半L2 cache小10%, 講成本就已經差好遠

唔知佢可能佢覺得 hit rate 可以打救 latency
或者一時糊塗後果到 XV 先開始有得修正但 XV 之後就係 Z...
於是都係無得救

[ 本帖最後由 Puff 於 2014-7-16 21:55 編輯 ]

作者: qcmadness 時間: 2014-7-16 21:56

引用:

原帖由 Puff 於 2014-7-16 21:54 發表

唔知佢可能佢覺得 hit rate 可以打救 latency
或者一時糊塗後果到 XV 先開始有得修正

由Bulldozer的8150, 我已經覺得佢因為L2 cache犠牲太多

作者: Puff 時間: 2014-7-16 21:57

引用:

原帖由 qcmadness 於 2014-7-16 21:56 發表

由Bulldozer的8150, 我已經覺得佢因為L2 cache犠牲太多

或者其實 1MB 版本係俾 2C die 用... 不過 Llano2 同打後 Trinity2 全部瓜柴
Kaveri 可能連 plan 都無 plan 過

作者: qcmadness 時間: 2014-7-16 21:57

引用:

原帖由 Puff 於 2014-7-16 21:57 發表

或者其實 1MB 版本係俾 2C die 用... 不過 Llano2 同 Trinity2 全部瓜柴

唔會, Bulldozer Gen 1係用落純CPU度

作者: dom 時間: 2014-7-16 21:58

2MB L2 , 咁熟口面既....

作者: Puff 時間: 2014-7-16 21:58

引用:

原帖由 qcmadness 於 2014-7-16 21:57 發表

唔會, Bulldozer Gen 1係用落純CPU度

IIRC PD = 字面上的 BD rev
唔差得遠

作者: qcmadness 時間: 2014-7-16 22:01

引用:

原帖由 dom 於 2014-7-16 21:58 發表
2MB L2 , 咁熟口面既....

Kaveri Next Gen

作者: dom 時間: 2014-7-16 22:02

引用:

原帖由 qcmadness 於 2014/7/16 22:01 發表

Kaveri Next Gen

定係 Kaveri 2.0 ( Trinity -> Richland ) 咁小改

作者: Puff 時間: 2014-7-16 22:03

希望佢 16 新架構走返低延遲 private L2 路線唔該
只不過唔知係搭 big inclusive LLC 定 optional exclusive LLC + optional dir
後者機會大D 因為我睇開AMD堆專利同research paper...

[ 本帖最後由 Puff 於 2014-7-16 22:06 編輯 ]

作者: qcmadness 時間: 2014-7-16 22:03

引用:

原帖由 dom 於 2014-7-16 22:02 發表

定係 Kaveri 2.0 ( Trinity -> Richland ) 咁小改

大改

作者: Puff 時間: 2014-7-16 22:04

引用:

原帖由 dom 於 2014-7-16 22:02 發表

定係 Kaveri 2.0 ( Trinity -> Richland ) 咁小改

XV 核心貌似支援唔少新野根據 GCC patch 資料 AVX2, TSX 都有
物理實作一兩年前話 XV 呢代開始再加重多一重用電腦自動化設計

至於大體上講 CZ 就等於 KV SOC 版

作者: qcmadness 時間: 2014-7-16 22:05

引用:

原帖由 Puff 於 2014-7-16 22:03 發表
希望佢新架構走返低延遲 private L2 路線唔該
只不過唔知係搭 big inclusive LLC 定 optional exclusive LLC + optional dir
後者機會大D 因為我睇開AMD堆專利同research paper...

...

多數唔會

睇Bulldozer / Jaguar既trend, 應該係玩shared L2 cache,
至於load-to-use latency, 我諗以Jaguar行緊25-cycle latency @ half-speed, 你都唔好有太大期望了

作者: Puff 時間: 2014-7-16 22:13

引用:

原帖由 qcmadness 於 2014-7-16 22:05 發表

多數唔會

睇Bulldozer / Jaguar既trend, 應該係玩shared L2 cache,
至於load-to-use latency, 我諗以Jaguar行緊25-cycle latency @ half-speed, 你都唔好有太大期望了

我咁睇一個本身就為共享而共享一個四核低成本low-power 最初大貓都唔係開心share
我自己超樂觀預期係 14nm KV/Beema呢兩級APU全部跌watt落雙核用同一粒核心差別只係GPU/HBM

[ 本帖最後由 Puff 於 2014-7-16 22:14 編輯 ]

作者: qcmadness 時間: 2014-7-16 22:14

引用:

原帖由 Puff 於 2014-7-16 22:13 發表

我咁睇一個本身就為共享而共享一個四核低成本low-power 最初大貓都唔係開心share
我自己超樂觀預期係 14nm KV/Beema呢兩級APU全部跌watt落雙核用同一粒核心差別只係GPU/HBM
...

Jaguar要share係因為個pool大左, 就唔駛咁bandwidth dependent
亦都算係對multi-core inter-core bandwidth有d進步

對住AMD唔好樂觀, 呢個係我呢10年的經驗

作者: Puff 時間: 2014-7-16 22:16

引用:

原帖由 qcmadness 於 2014-7-16 22:14 發表

Jaguar要share係因為個pool大左, 就唔駛咁bandwidth dependent
亦都算係對multi-core inter-core bandwidth有d進步

我記得佢有提過話係 single thread/latency 平衡。
意即得一粒 core 重負荷成個L2都係佢玩晒 hitrate高D 於是IPC都高D 而佢地條數話抵銷完L2 latency 高左都係正能量

作者: qcmadness 時間: 2014-7-16 22:17

引用:

原帖由 Puff 於 2014-7-16 22:16 發表

我記得佢有提過話係 single thread/latency 平衡。
意即得一粒 core 重負荷成個L2都係佢玩晒 hitrate高D 於是IPC都高D 而佢地條數話抵銷完L2 latency 高左都係正能量 ...

所以以後都shared L2 cache咪可能成為事實

作者: Puff 時間: 2014-7-16 22:18

引用:

原帖由 qcmadness 於 2014-7-16 22:14 發表

對住AMD唔好樂觀, 呢個係我呢10年的經驗

無因為有夢發所以知道些少消息諗住應該可以提高下底線咁
不過位周公已經跳槽去左食生果

抄 I***t 高 IPC + SMT 喎

作者: Puff 時間: 2014-7-16 22:23

引用:

原帖由 qcmadness 於 2014-7-16 22:17 發表

所以以後都shared L2 cache咪可能成為事實

咁... 咁雙核共享L2囉 Cyclone L2 聽講得 ~12 cycle (anandtech 話 Swift 1/2)
雖然佢最高跑到 1.6 Ghz

[ 本帖最後由 Puff 於 2014-7-16 22:26 編輯 ]

作者: qcmadness 時間: 2014-7-16 22:25

引用:

原帖由 Puff 於 2014-7-16 22:23 發表

咁... 咁雙核共享L2囉 Cyclone L2 聽講得 ~12 cycle 雖然佢最高跑到 1.6 Ghz

要低latency係好麻煩架
而且而家要將Jaguar再進化, 係要提升clock speed同加大execution resource行先lor

作者: Puff 時間: 2014-7-16 22:27

引用:

原帖由 qcmadness 於 2014-7-16 22:25 發表

要低latency係好麻煩架
而且而家要將Jaguar再進化, 係要提升clock speed同加大execution resource行先lor

佢話 built from clean sheet 但執依家已經有既藥方黎用嘛咁梗係估一砲過

作者: qcmadness 時間: 2014-7-16 22:28

引用:

原帖由 Puff 於 2014-7-16 22:27 發表

佢話 built from clean sheet 嘛咁梗係估一砲過

無呢樣野的, 聽佢地吹啦

microarchitecture個理念全新, 我相信可以
但係ALU/FMA/SSEx/MC呢d野, 無可能全新, 一定係抄舊再改良

作者: Puff 時間: 2014-7-16 22:32

引用:

原帖由 qcmadness 於 2014-7-16 22:28 發表

無呢樣野的, 聽佢地吹啦

microarchitecture個理念全新, 我相信可以
但係ALU/FMA/SSEx/MC呢d野, 無可能全新, 一定係抄舊再改良

我都知所謂 uarch 咪只係你點將呢堆野癡埋一舊然後做好個 balance
但執依家已經有既藥方黎用嘛 <-

[ 本帖最後由 Puff 於 2014-7-16 22:35 編輯 ]

作者: qcmadness 時間: 2014-7-16 22:34

引用:

原帖由 Puff 於 2014-7-16 22:32 發表

我都知所謂 uarch 咪只係你點將呢堆野癡埋一舊然後做好個 balance
但執依家已經有既藥方黎用嘛

個人認為會走short-pipeline + low-power路線

作者: Puff 時間: 2014-7-16 22:41

引用:

原帖由 qcmadness 於 2014-7-16 22:34 發表

個人認為會走short-pipeline + low-power路線

short pipeline = clock 唔會高得去邊 L2 latency 唔係大問題
但老實講 Cat/SNB/Cyclone 全部都唔長得去邊

我咁睇 Cat 28nm都爆到上2.4Ghz FinFET+少少trade-off保持KV移動版水平(3.2-3.6Ghz) 都應該得掛當然此前呢個theory成唔成立有據稱全面用HDL既XV可以觀望

[ 本帖最後由 Puff 於 2014-7-16 22:42 編輯 ]

作者: qcmadness 時間: 2014-7-16 22:46

引用:

原帖由 Puff 於 2014-7-16 22:41 發表

short pipeline = clock 唔會高得去邊 L2 latency 唔係大問題
但老實講 Cat/SNB/Cyclone 全部都唔長得去邊

我咁睇 Cat 28nm都爆到上2.4Ghz FinFET+少少trade-off保持KV移動版水平(3.2-3.6Ghz) 都應該得掛當然此 ...

Jaguar同Bobcat已經差好遠, 同pipeline有關, 再改有機上到3GHz左右

作者: Puff 時間: 2014-7-16 23:04

引用:

原帖由 qcmadness 於 2014-7-16 22:46 發表

Jaguar同Bobcat已經差好遠, 同pipeline有關, 再改有機上到3GHz左右

查實依家全系列都走 low power 路線

我自己做個預期整理就係 high IPC core (moderately clocked, max 3.2-3.6ghz)
依家細SOC轉雙核(<17W) 大SOC都轉雙核搭HBM(<37W NB/<55W DT)
然後加一級四核APU搭HBM(<125W) SOC TDP越高 CPU功耗佔比例就越少
AMD俾資料係四粒HBM夾埋512GB/s PHY同DRAM合計燒你30W 即係每粒7W

作者: qcmadness 時間: 2014-7-16 23:05

引用:

原帖由 Puff 於 2014-7-16 23:04 發表

查實依家全系列都走 low power 路線

我自己做個預期整理就係 high IPC core (moderately clocked, max 3.2-3.6ghz)
依家細SOC轉雙核(

超過3GHz有一定難度

作者: Puff 時間: 2014-7-16 23:10

引用:

原帖由 qcmadness 於 2014-7-16 23:05 發表

超過3GHz有一定難度

呢個預期係建基於粒核心有HSW咁大粒
如果係估計top 3GHz+max area efficiency 咁中間SOC四核可以諗諗
大大粒SOC可以多D伺服器特性可能帶L3$同NUMA capable掛

作者: qcmadness 時間: 2014-7-16 23:11

引用:

原帖由 Puff 於 2014-7-16 23:10 發表

呢個預期係建基於粒核心有HSW咁大粒
如果係估計top 3GHz+max area efficiency 咁中間SOC四核可以諗諗
大大粒SOC可以多D伺服器特性可能帶L3$同NUMA capable掛
...

同Intel鬥堆transistor, AMD一定輸, 要記住呢點

作者: Puff 時間: 2014-7-16 23:12

引用:

原帖由 qcmadness 於 2014-7-16 23:11 發表

同Intel鬥堆transistor, AMD一定輸, 要記住呢點

當然但依家 transistor 佔大頭係 GPU
反正主要就係估 x86 core convergence + 細SOC 雙核

作者: qcmadness 時間: 2014-7-16 23:16

引用:

原帖由 Puff 於 2014-7-16 23:12 發表

當然但依家 transistor 佔大頭係 GPU
反正主要就係估 x86 core convergence + 細SOC 雙核

以projection計, 如果又係20% IPC + 20% clock speed @ 50% power consumption, 咁下代cat series就會係40W TDP + Trinity-class performance

作者: Puff 時間: 2014-7-16 23:17

引用:

原帖由 qcmadness 於 2014-7-16 23:16 發表

以projection計, 如果又係20% IPC + 20% clock speed @ 50% power consumption, 咁下代cat series就會係40W TDP + Trinity-class performance

都話叫 Zen 僅此一粒 x86

作者: qcmadness 時間: 2014-7-16 23:18

引用:

原帖由 Puff 於 2014-7-16 23:17 發表

都話叫 Zen 僅此一粒 x86

你聽佢up啦

作者: Puff 時間: 2014-7-16 23:19

引用:

原帖由 qcmadness 於 2014-7-16 23:18 發表

你聽佢up啦

呃你無飯食 S|A都有提

作者: qcmadness 時間: 2014-7-16 23:19

引用:

原帖由 Puff 於 2014-7-16 23:19 發表

呃你無飯食 S|A都有提

S|A成日流料, 你信佢啦

作者: Puff 時間: 2014-7-16 23:22

引用:

原帖由 qcmadness 於 2014-7-16 23:19 發表

S|A成日流料, 你信佢啦

反正 16 年打後得一粒 x86 同一粒 ARM 我是信的
一個向上打一個向下打

作者: qcmadness 時間: 2014-7-16 23:29

引用:

原帖由 Puff 於 2014-7-16 23:22 發表

反正 16 年打後得一粒 x86 同一粒 ARM 我是信的
一個向上打一個向下打

ARM... 我覺得AMD唔會太落力
x86反而我覺得所謂的"1個core"係有得玩野的

作者: Puff 時間: 2014-7-16 23:35

引用:

原帖由 qcmadness 於 2014-7-16 23:29 發表

ARM... 我覺得AMD唔會太落力
x86反而我覺得所謂的"1個core"係有得玩野的

只不過覺得兩粒真係無乜需要
HSW已經証明一粒可以打到幾多個segment 然後再向下打都係ARM地頭

作者: qcmadness 時間: 2014-7-16 23:37

引用:

原帖由 Puff 於 2014-7-16 23:35 發表

只不過覺得兩粒真係無乜需要
HSW已經証明一粒可以打到幾多個segment 然後再向下打都係ARM地頭

個人覺得AMD唔係咁信ARM, server side要行hybrid
mobile side個問題唔單止係個power consumption度

當然Jaguar其實仲有唔小空間降低功耗, 不過AMD無做

作者: Puff 時間: 2014-7-16 23:43

引用:

原帖由 qcmadness 於 2014-7-16 23:37 發表

個人覺得AMD唔係咁信ARM, server side要行hybrid
mobile side個問題唔單止係個power consumption度

當然Jaguar其實仲有唔小空間降低功耗, 不過AMD無做

server side 主流根本就係 x86 獨市係高端大大部先叫有其他特別選擇
ARMv8 server 依家目標只係做 OSS cloud web tier/big data cluster
發夢話 AMD 搞 ARM 都係為做呢範我估大概係想做埋 NFV/networking 同嵌入(連手持)掛

mobile 呢? 基本上可以叫 ARM 獨市, Intel 打極都唔入流...
當然 sofia/airmont 可能會改變下現狀但多數係點心照

[ 本帖最後由 Puff 於 2014-7-16 23:44 編輯 ]

作者: qcmadness 時間: 2014-7-16 23:51

引用:

原帖由 Puff 於 2014-7-16 23:43 發表

server side 主流根本就係 x86 獨市係高端大大部先叫有其他特別選擇
ARMv8 server 依家目標只係做 OSS cloud web tier/big data cluster
發夢話 AMD 搞 ARM 都係為做呢範我估大概係想做埋 NFV/networking 同嵌入( ...

Intel從來都唔係輸效能, 係輸價格, 呢點反而AMD唔會想入呢個market

Data cluster用x86仲有d優勢

作者: Puff 時間: 2014-7-17 00:15

引用:

原帖由 qcmadness 於 2014-7-16 23:51 發表

Intel從來都唔係輸效能, 係輸價格, 呢點反而AMD唔會想入呢個market

依家有hybrid node難講至少功耗上無咁輸蝕掛係規模無得鬥咁解

作者: qcmadness 時間: 2014-7-17 18:45

引用:

原帖由 Puff 於 2014-7-17 00:15 發表

依家有hybrid node難講至少功耗上無咁輸蝕掛係規模無得鬥咁解

一樣會輸, 主要係肯唔肯俾心機

作者: Puff 時間: 2014-7-17 19:33

重新諗過一輪 shared cache
hitrate/latency balance 唔係根本原因 (512KB + prefetching 已經夠玩晒啦)
大部份 PC app 都係 latency 行先再講獨立 L2 = 有 per-core power gating 你玩...

反而似係 cache coherency/power 比較多
依家除左 console SOC 外所有大貓 chip 都等同有個 shared LLC... 於是除左 I/O request 外可以唔洗 probing 直踩 DRAM

繼續坐 Shared 1MB 望獨立 512KB L2

[ 本帖最後由 Puff 於 2014-7-17 19:36 編輯 ]

作者: qcmadness 時間: 2014-7-17 19:38

引用:

原帖由 Puff 於 2014-7-17 19:33 發表
重新諗過一輪 shared cache
hitrate/latency balance 唔係根本原因 (512KB + prefetching 已經夠玩晒啦)
大部份 PC app 都係 latency 行先再講獨立 L2 = 有 per-core power gating 你玩...

反而似係 cache coheren ...

信我啦, 唔會有獨立llc

作者: Puff 時間: 2014-7-17 19:45

引用:

原帖由 qcmadness 於 2014-7-17 19:38 發表

信我啦, 唔會有獨立llc

我係估獨立 L2 + optional L3 + optional CG directory

作者: qcmadness 時間: 2014-7-17 19:46

引用:

原帖由 Puff 於 2014-7-17 19:45 發表

我係估獨立 L2 + optional L3 + optional directory

APU呀, 你估server CPU咩

作者: Puff 時間: 2014-7-17 19:47

引用:

原帖由 qcmadness 於 2014-7-17 19:46 發表

APU呀, 你估server CPU咩

重點是 optional. 低階 APU 咪唔帶 L3/Dir，齋兩粒 core 然後繼續 probing 到天荒地老。另外仲有 new GPU cache hierarchy + region-level coherence protocol

作者: qcmadness 時間: 2014-7-17 19:48

引用:

原帖由 Puff 於 2014-7-17 19:47 發表

重點是 optional. APU 咪唔帶 L3/Dir. 另外仲有 new GPU cache hierarchy + region-level coherence protocol

算把啦

industrial trend用shared cache, 自然唔係無原因的, 除非AMD傻左啦

作者: Puff 時間: 2014-7-17 19:49

引用:

原帖由 qcmadness 於 2014-7-17 19:48 發表

算把啦

industrial trend用shared cache, 自然唔係無原因的, 除非AMD傻左啦

咁你將獨立 L2 換做 Shared L2 per 2 core

作者: qcmadness 時間: 2014-7-17 19:49

引用:

原帖由 Puff 於 2014-7-17 19:49 發表

咁你將獨立 L2 換做 Shared L2 per 2 core

都未必tim呀

當然後年出自有分曉

作者: Puff 時間: 2014-7-17 19:52

引用:

原帖由 qcmadness 於 2014-7-17 19:49 發表

都未必tim呀

當然後年出自有分曉

Seattle 聽講係 Shared 1MB per 2 core. L3 唔洗講
至於 exclusive L3 同 region level directory 成數唔少
AMD 自家 APU simulator 已經係咁既架構呢幾年出唔少 paper
最重要係可以擴展去支援更高層次的 GPU cache coherency (依家只係 write-thru)

歡迎光臨 HKSpot (https://bbs.hk-spot.com/)