http://ati.amd.com/developer/cgo/2008/Rubin-CGO2008.pdf
page34
5way VLIW issue使用率：
bioshock: 4.22
call of juarez: 3.92
crysis: 3.80
lostplanet: 3.38
根據RacingPHT兄的說法，360某些title的shader使用率上比R600更差些，如lost planet….
compiler是個很麻煩的東西，GPU的shader由於在執行前已經分配過資源，所以理論上不會有deadlock；但是shader compiler雖然相對一般compiler來說比較單純，可是GPU因為update得勤，結果常常得面對一個compiler用在很多chip上的狀況。
那個blinn’s law很有趣XD
因為moors’ law的關係，影業即使每個frame可以使用的render time是固定的(每分鐘frame需要十萬分鐘render)，每年的運算能量仍然會進步，結果就是品質預期可以不停進步。
但是GPU勢必得1:1輸出的關係，結果變成如果要電影等級的化，user變成在預期有一台十萬倍快的機器XD
當然CPU和GPU目前在繪圖上的速度差其實也頂多上百倍….
—–
http://s08.idav.ucdavis.edu/
SIGGRAPH 2008: Beyond Programmable Shading
有paper快抓XD
360初期的shader compiler效率不太好.
因為是第一個US,全新的架構,新的compiler….
後期有大幅度改善.
R600也是類似情形, shader效率隨driver改版
而一直進步.
shader comiler的工作相對簡單,
所以效率可以很高.
能夠越來越接近峰值效能.
但shader code也要少用一點register.
因為thread的數量直接影響GPU效能.
shader comiler只能幫你把指令reorder.
如果開發者用了太多不必要的register,
comiler也無能為力.
把一堆float的數據pack到vec4也是最佳化.
因為GPU的register其實都是4D的.
Less registers are better, because of threading….就是這個意思.
那個VLIW使用率可能跟遊戲shader複雜度有關.
compiler能力是相同的,硬體也是相同的,
差異來自於shader code的複雜度與寫法.
LP是以shader用量而言算是很少,計算量也不多.
如果shader code不夠長,那compiler也較難找到
可以reorder的機會.
越短的shader通常前後指令的資料有依存性的機率越大.
隨著遊戲shader越來越複雜,VLIW ALU應該越來越容易
維持80%以上滿載率.
crisis應該有很複雜的shader.
可能是寫法的問題導致效能浪費.
難怪他這麼吃硬體.
360初期的shader compiler效率不太好.
因為是第一個US,全新的架構,新的compiler….
後期有大幅度改善.
R600也是類似情形, shader效率隨driver改版
而一直進步.
shader comiler的工作相對簡單,
所以效率可以很高.
能夠越來越接近峰值效能.
但shader code也要少用一點register.
因為thread的數量直接影響GPU效能.
shader comiler只能幫你把指令reorder.
如果開發者用了太多不必要的register,
comiler也無能為力.
把一堆float的數據pack到vec4也是最佳化.
因為GPU的register其實都是4D的.
Less registers are better, because of threading….就是這個意思.
那個VLIW使用率可能跟遊戲shader複雜度有關.
compiler能力是相同的,硬體也是相同的,
差異來自於shader code的複雜度與寫法.
LP是以shader用量而言算是很少,計算量也不多.
如果shader code不夠長,那compiler也較難找到
可以reorder的機會.
越短的shader通常前後指令的資料有依存性的機率越大.
隨著遊戲shader越來越複雜,VLIW ALU應該越來越容易
維持80%以上滿載率.
crisis應該有很複雜的shader.
可能是寫法的問題導致效能浪費.
難怪他這麼吃硬體.
shock: 4.22 /5
call of juarez: 3.92 /5
crysis: 3.80 /5
lostplanet: 3.38/5
效率高到令人震撼, 如果真的有這么高, 還會輸給G80那么多, 那就是吸收延遲的threads技術沒有弄好.
或統計有誤.
shock: 4.22 /5
call of juarez: 3.92 /5
crysis: 3.80 /5
lostplanet: 3.38/5
效率高到令人震撼, 如果真的有這么高, 還會輸給G80那么多, 那就是吸收延遲的threads技術沒有弄好.
或統計有誤.
GPU的shader unit雖然很重要,
但是其實fixed function unit的工作量更大.
shader需要從Tex unit輸入資料才能運作,
R600配置的ALU/TEX比例太過頭了.
導致空有大量ALU+大量的Thread,卻還是ALU閒置.
VLIW issue使用率是以shader程式碼在
GPU Shader Analyzer之類的工具分析的.
並沒有考慮到TEX指令的問題.
(因為TEX的cycle數會隨AF的高低而不同,沒有固定)
http://www.beyond3d.com/…filter-4×4-bilinear.png
R600的TEX和ROP太少(16TEX/16ROP)是輸G80的主因, G80是32TEX/24ROP.
R600完全維持上一代X1950的配置沒有進步…..
論ALU運算力其實R600是不輸G80,甚至超過.
但這優勢又被軟體做MSAA resolve
吃掉一些shader運算力而抵銷掉一些.
所以R600其實不是輸在可程式化shader core.
而是輸在fixed function unit的TEX, ROP(MSAA)…
GPU的shader unit雖然很重要,
但是其實fixed function unit的工作量更大.
shader需要從Tex unit輸入資料才能運作,
R600配置的ALU/TEX比例太過頭了.
導致空有大量ALU+大量的Thread,卻還是ALU閒置.
VLIW issue使用率是以shader程式碼在
GPU Shader Analyzer之類的工具分析的.
並沒有考慮到TEX指令的問題.
(因為TEX的cycle數會隨AF的高低而不同,沒有固定)
http://www.beyond3d.com/…filter-4×4-bilinear.png
R600的TEX和ROP太少(16TEX/16ROP)是輸G80的主因, G80是32TEX/24ROP.
R600完全維持上一代X1950的配置沒有進步…..
論ALU運算力其實R600是不輸G80,甚至超過.
但這優勢又被軟體做MSAA resolve
吃掉一些shader運算力而抵銷掉一些.
所以R600其實不是輸在可程式化shader core.
而是輸在fixed function unit的TEX, ROP(MSAA)…
去http://s08.idav.ucdavis.edu/
看了Larrabee的新ppt, 有了新發現:
“Task-parallel algorithm captured on-chip locality”
原來larrabee是期望引導未來的繪圖應用走向 — 試圖更多利用上各類區域性locality.
而cuda是期望引導未來的軟件應用走向 — 試圖更多利用上多線程延遲吸收.
larrabee是CPU卻想改造GPU應用的發展模式.
而GTX280是GPU卻想改造CPU應用的發展模式.
區域性與線程的戰爭開始了!!
larrabee是線程上的弱者,on-chip locality區域性上的強者.
而GPU是線程上的強者, 更適合繪圖!!
larrabee的硬件線程HW threads是極為稀少的, 其任務task是基于軟體的偽thread, 其實就是call-function類型的的program, 延遲吸收的關鍵是異步訪存, 或力爭集中提前下達傳輸texture等資料指令.
去http://s08.idav.ucdavis.edu/
看了Larrabee的新ppt, 有了新發現:
“Task-parallel algorithm captured on-chip locality”
原來larrabee是期望引導未來的繪圖應用走向 — 試圖更多利用上各類區域性locality.
而cuda是期望引導未來的軟件應用走向 — 試圖更多利用上多線程延遲吸收.
larrabee是CPU卻想改造GPU應用的發展模式.
而GTX280是GPU卻想改造CPU應用的發展模式.
區域性與線程的戰爭開始了!!
larrabee是線程上的弱者,on-chip locality區域性上的強者.
而GPU是線程上的強者, 更適合繪圖!!
larrabee的硬件線程HW threads是極為稀少的, 其任務task是基于軟體的偽thread, 其實就是call-function類型的的program, 延遲吸收的關鍵是異步訪存, 或力爭集中提前下達傳輸texture等資料指令.
> 效率高到令人震撼, 如果真的有這么高, 還會輸給G80那么多, 那就是吸收延遲的threads技術沒有弄好.
compiler效率比想像中好很多，所以ATI當初選擇5D VLIW是可以接受的。
會輸G80的理由waffenSS兄提過，主因是TMU和ROP的絕對性能不足，所以我們可以看到RV770在這方面補強(TMU16加到40、ROP單位性能double)之後立刻得到改進；當然能補強這點也是和製程承載能力有關，才能回到全面crossbar的設計。
不過我覺得R600的TMU和RV770相比其實單位性能是比較好的，只是那個共用L1/L2的設計太虛了些。
> 效率高到令人震撼, 如果真的有這么高, 還會輸給G80那么多, 那就是吸收延遲的threads技術沒有弄好.
compiler效率比想像中好很多，所以ATI當初選擇5D VLIW是可以接受的。
會輸G80的理由waffenSS兄提過，主因是TMU和ROP的絕對性能不足，所以我們可以看到RV770在這方面補強(TMU16加到40、ROP單位性能double)之後立刻得到改進；當然能補強這點也是和製程承載能力有關，才能回到全面crossbar的設計。
不過我覺得R600的TMU和RV770相比其實單位性能是比較好的，只是那個共用L1/L2的設計太虛了些。
crysis理应用这一代的高阶绘图卡就能跑顺畅，现在高阶SLI都无法流畅肯定是哪里出了问题
crysis理应用这一代的高阶绘图卡就能跑顺畅，现在高阶SLI都无法流畅肯定是哪里出了问题
> larrabee的硬件線程HW threads是極為稀少的, 其任務task是基于軟體的偽thread, 其實就是call-function類型的的program, 延遲吸收的關鍵是異步訪存, 或力爭集中提前下達傳輸texture等資料指令.
你對thread很有執念喔。老是用「很稀少」這幾個字來講這件事情XD
Larrabee的硬體SMT的作用，只需要對抗從L2到L1交換的時候可能產生的無預警延遲而已，如果是要吸收TMU延遲，就像你講的，光靠cache內的program change(模擬GPU的warp交換)就很充分了，畢竟fiber可以隨便開。
> larrabee的硬件線程HW threads是極為稀少的, 其任務task是基于軟體的偽thread, 其實就是call-function類型的的program, 延遲吸收的關鍵是異步訪存, 或力爭集中提前下達傳輸texture等資料指令.
你對thread很有執念喔。老是用「很稀少」這幾個字來講這件事情XD
Larrabee的硬體SMT的作用，只需要對抗從L2到L1交換的時候可能產生的無預警延遲而已，如果是要吸收TMU延遲，就像你講的，光靠cache內的program change(模擬GPU的warp交換)就很充分了，畢竟fiber可以隨便開。
又看了larrabee新pdf
forsyth-larrabee-graphics-architecture.pdf
larrabee公開了其software rander在各個work上的使用比率.
P26:
Frontend: ~10% of clock cycles 對應VS等
– Find positions of vertices
– Add triangles to correct bins
Either front or back: ~20% of clock cycles 對應光柵Rasterisation處理~20%
– Attribute shading, clipping, tessellation
– Rasterisation
Backend: ~70% of clock cycles 對應PS與ROP~70%
– Pick up a bin, shade & blend into tile
– Completely standard pipeline within that tile
看來似乎, Rasterisation就要要消耗20%的運算力, 而ROP是??
還有,是靠larrabee來動態編譯shader,而非CPU. 與現行CPU-GPU協作模式有很大區別.
• Many stages are built from JITted code
– We JIT shaders just like normal GPUs
– But JITting happens on Larrabee, not the host
請教耐心的Eji.
又看了larrabee新pdf
forsyth-larrabee-graphics-architecture.pdf
larrabee公開了其software rander在各個work上的使用比率.
P26:
Frontend: ~10% of clock cycles 對應VS等
– Find positions of vertices
– Add triangles to correct bins
Either front or back: ~20% of clock cycles 對應光柵Rasterisation處理~20%
– Attribute shading, clipping, tessellation
– Rasterisation
Backend: ~70% of clock cycles 對應PS與ROP~70%
– Pick up a bin, shade & blend into tile
– Completely standard pipeline within that tile
看來似乎, Rasterisation就要要消耗20%的運算力, 而ROP是??
還有,是靠larrabee來動態編譯shader,而非CPU. 與現行CPU-GPU協作模式有很大區別.
• Many stages are built from JITted code
– We JIT shaders just like normal GPUs
– But JITting happens on Larrabee, not the host
請教耐心的Eji.
而larrabee認為游戲的典型耗時比例是:
First approximation profile for modern games:
– 70% pixel setup + shading
– 10% depth
– 10% rasterization, 什么?rasterization才10%?
– 10% vertex shading (expected – see above) VS才10%?
還有vpu的isa, Eji基本上是對的. 看來效率還可以.
Gather/scatter instructions
– Reads/writes 16 results to/from 16 different offsets
– With predication, allows “dataflow” processing
Take scalar code without aliasing, auto-SIMDise
Including loops, conditionals, calls, stacks, etc
Maps to shader-style languages really well
而vpu寄存器數量是Large number? 多少算Large number? 16個還是64個。
要是平均到每個thread里應該還是很少吧?
16-wide float32/int32, 8-wide float64
– Large number of 512-bit registers
– Ternary, multiply-add, one clock throughput
– One source can come from memory for free
– Most instructions have
而larrabee認為游戲的典型耗時比例是:
First approximation profile for modern games:
– 70% pixel setup + shading
– 10% depth
– 10% rasterization, 什么?rasterization才10%?
– 10% vertex shading (expected – see above) VS才10%?
還有vpu的isa, Eji基本上是對的. 看來效率還可以.
Gather/scatter instructions
– Reads/writes 16 results to/from 16 different offsets
– With predication, allows “dataflow” processing
Take scalar code without aliasing, auto-SIMDise
Including loops, conditionals, calls, stacks, etc
Maps to shader-style languages really well
而vpu寄存器數量是Large number? 多少算Large number? 16個還是64個。
要是平均到每個thread里應該還是很少吧?
16-wide float32/int32, 8-wide float64
– Large number of 512-bit registers
– Ternary, multiply-add, one clock throughput
– One source can come from memory for free
– Most instructions have
Most instructions have
Most instructions have
– Most instructions have much less than 8-clock latency
vpu指令延遲是非一致的!! 有的高達8 clock–可能是fuse-muladd指令?
而texture unit是全功能full DirectX/OpenGL functionality. 似乎就是一個正常的texture sampler unit:
Texture sampler units
– Full DirectX/OpenGL functionality
– Have their own semi-coherent caches
– Same virtual memory space as the cores
另外texture cache只有節省頻寬的用途, 而無法隱蔽延遲.
Texture caches are special
– Semi-streaming data – some locality
– Caches save bandwidth, but can’t hide latency
是靠切換fiber來隱蔽延遲–當fiber請求texture request后就切換了.
Fiber switch on texture request submission
– Saves live registers
– Saves the IP to resume at
– Jumps to the next fiber’s IP
– Next fiber restores live registers
– Gets texture result, continues shading
很有趣的是HW threads,里面僅僅提到x86相關的reg等context, 是有full separate的4份. 而vpu的context呢? 看來有很大的玄機啊!! 每個線程的vpu reg可能是共享的? 或者part separate的? 這是核心技術啊!! 應該有很大的magic!!
Each core has 4 hardware threads
– Each thread is a full separate x86 context
請教耐心的Eji.
– Most instructions have much less than 8-clock latency
vpu指令延遲是非一致的!! 有的高達8 clock–可能是fuse-muladd指令?
而texture unit是全功能full DirectX/OpenGL functionality. 似乎就是一個正常的texture sampler unit:
Texture sampler units
– Full DirectX/OpenGL functionality
– Have their own semi-coherent caches
– Same virtual memory space as the cores
另外texture cache只有節省頻寬的用途, 而無法隱蔽延遲.
Texture caches are special
– Semi-streaming data – some locality
– Caches save bandwidth, but can’t hide latency
是靠切換fiber來隱蔽延遲–當fiber請求texture request后就切換了.
Fiber switch on texture request submission
– Saves live registers
– Saves the IP to resume at
– Jumps to the next fiber’s IP
– Next fiber restores live registers
– Gets texture result, continues shading
很有趣的是HW threads,里面僅僅提到x86相關的reg等context, 是有full separate的4份. 而vpu的context呢? 看來有很大的玄機啊!! 每個線程的vpu reg可能是共享的? 或者part separate的? 這是核心技術啊!! 應該有很大的magic!!
Each core has 4 hardware threads
– Each thread is a full separate x86 context
請教耐心的Eji.
>>First approximation profile
>>for modern games:
>>– 70% pixel setup + shading
>>– 10% depth
>>– 10% rasterization,
>>– 10% vertex shading
>> (expected – see above)
VS的工作量是固定值,與解析度無關,
(模型頂點數量是固定的)
所以解析度越高(Pixel量), VS佔的比例就會偏低.
它以2005~2007年的遊戲測2009年的硬體.
解析度可以從原本720P拉高到1600*1200.
Pixel的workload大了2倍.
所以VS的相對比例變得很低.
那比例是預估的,
不過2年後的事很難講,只能參考參考.
它都是用舊遊戲推測, 並沒考慮到DX11的TS unit
和DX10的GS的影響….
這有點像拿Xbox1的遊戲來推測X360遊戲的workload.
不用太認真去看數字….
JITted code不知道是寫什麼….
>>First approximation profile
>>for modern games:
>>– 70% pixel setup + shading
>>– 10% depth
>>– 10% rasterization,
>>– 10% vertex shading
>> (expected – see above)
VS的工作量是固定值,與解析度無關,
(模型頂點數量是固定的)
所以解析度越高(Pixel量), VS佔的比例就會偏低.
它以2005~2007年的遊戲測2009年的硬體.
解析度可以從原本720P拉高到1600*1200.
Pixel的workload大了2倍.
所以VS的相對比例變得很低.
那比例是預估的,
不過2年後的事很難講,只能參考參考.
它都是用舊遊戲推測, 並沒考慮到DX11的TS unit
和DX10的GS的影響….
這有點像拿Xbox1的遊戲來推測X360遊戲的workload.
不用太認真去看數字….
JITted code不知道是寫什麼….
>JITted code不知道是寫什麼….
是即時編譯器 JIT–just in time, 例如java的JIT編譯器.
另外, 來想一下vpu reg是如何分配給fiber使用的.
用vreg 表示 vector register. 并假設vreg是有64個/core.
有可能是多個fiber是共享vpu reg的, 與一般理解的SMT是有很大區別的.
例如,有的情況下,shader編譯器是把
vreg0,vreg1分配給fiber A使用
vreg2,vreg3分配給fiber B使用
…..
如此一下,fiber A就不會干擾其他的fiber B了.
而且有可能連HW threads都是共享vpu reg的,是直接顯式使用vpu reg. 沒有什么利用硬件來SMT分割vpu reg的行為.
例如是:有的情況下, 用shader編譯控制軟體把
vreg0到vreg20分配給threads A
vreg21到vreg40分配給threads B
vreg41到vreg63分配給threads B
fiber軟件本身是知道自己是使用了哪個vreg, fiber其實是可以直接訪問全部vreg的, 而是靠編譯器軟體來保證fiber不會使用其他fiber的vreg. vreg是全局性的. 而局限在非thread內部的.
>JITted code不知道是寫什麼….
是即時編譯器 JIT–just in time, 例如java的JIT編譯器.
另外, 來想一下vpu reg是如何分配給fiber使用的.
用vreg 表示 vector register. 并假設vreg是有64個/core.
有可能是多個fiber是共享vpu reg的, 與一般理解的SMT是有很大區別的.
例如,有的情況下,shader編譯器是把
vreg0,vreg1分配給fiber A使用
vreg2,vreg3分配給fiber B使用
…..
如此一下,fiber A就不會干擾其他的fiber B了.
而且有可能連HW threads都是共享vpu reg的,是直接顯式使用vpu reg. 沒有什么利用硬件來SMT分割vpu reg的行為.
例如是:有的情況下, 用shader編譯控制軟體把
vreg0到vreg20分配給threads A
vreg21到vreg40分配給threads B
vreg41到vreg63分配給threads B
fiber軟件本身是知道自己是使用了哪個vreg, fiber其實是可以直接訪問全部vreg的, 而是靠編譯器軟體來保證fiber不會使用其他fiber的vreg. vreg是全局性的. 而局限在非thread內部的.
換句話說, 并非說是4 HW thread,就需要4份vreg copy. 而是需要4份x86/x87 reg的copy.
而vreg是靠編譯器軟體來分配vreg到各個thread或fiber的. 并非需要是4份 獨立的64個vregs. vreg是不會隨著thread切換而切換的.
簡單地說就是vreg沒有SMT化!!
換句話說, 并非說是4 HW thread,就需要4份vreg copy. 而是需要4份x86/x87 reg的copy.
而vreg是靠編譯器軟體來分配vreg到各個thread或fiber的. 并非需要是4份 獨立的64個vregs. vreg是不會隨著thread切換而切換的.
簡單地說就是vreg沒有SMT化!!
即時”編譯”很浪費效能也沒有必要性.
那個JIT code應該不是真的”即時編譯”.
而是類似shader那樣,在程式啟動前做compile.
CPU和GPU thread差異在於
CPU的thread一次要處理VS,GS,PS,ROP….
所以CPU thread很大很複雜,
而GPU的thread都是只處理很簡單的工作,
GPU thread小而單純.
靠一堆不同的thread接力完成工作.
而fiber就類似GPU的thread.
只不過是改靠軟體來做.
Larrabee的做法是用compiler事先把很多
不同的shader code或工作編譯成一個複雜X86 code.
不同shader使用不同組的vector register
JIT即時的部份應該是指即時做
同thread內的工作切換.
它有4組SMT thread,都是執行前compile好,
一個thread包含ABCD…很多個GPU工作.
ABCD…就是fiber.
一但遇到tex指令時,由於預期會有很長的latency,
compiler事先就插入特定的指令,告訴vector unit,
現在從thread的工作A跳到工作B.
把工作A的register內的東西save到cache.
從cache把工作B的資料restore調回register.
由於cache很大,理論上可以有很多fiber.
但問題還是在於效率,這還未知.
畢竟那是用軟體做的thread,要解決的問題很多,
如果fiber用的register太多,register不夠無法
在vector register事先放下一個fiber.
那切換fiber就必須從cache讀進來,恐怕會損失效能.
必須把上一個fiber寫回cache也是…..
編譯器的效率也是問題,雖然Intel很有經驗,
但是這比shader compiler要複雜多了.
即時”編譯”很浪費效能也沒有必要性.
那個JIT code應該不是真的”即時編譯”.
而是類似shader那樣,在程式啟動前做compile.
CPU和GPU thread差異在於
CPU的thread一次要處理VS,GS,PS,ROP….
所以CPU thread很大很複雜,
而GPU的thread都是只處理很簡單的工作,
GPU thread小而單純.
靠一堆不同的thread接力完成工作.
而fiber就類似GPU的thread.
只不過是改靠軟體來做.
Larrabee的做法是用compiler事先把很多
不同的shader code或工作編譯成一個複雜X86 code.
不同shader使用不同組的vector register
JIT即時的部份應該是指即時做
同thread內的工作切換.
它有4組SMT thread,都是執行前compile好,
一個thread包含ABCD…很多個GPU工作.
ABCD…就是fiber.
一但遇到tex指令時,由於預期會有很長的latency,
compiler事先就插入特定的指令,告訴vector unit,
現在從thread的工作A跳到工作B.
把工作A的register內的東西save到cache.
從cache把工作B的資料restore調回register.
由於cache很大,理論上可以有很多fiber.
但問題還是在於效率,這還未知.
畢竟那是用軟體做的thread,要解決的問題很多,
如果fiber用的register太多,register不夠無法
在vector register事先放下一個fiber.
那切換fiber就必須從cache讀進來,恐怕會損失效能.
必須把上一個fiber寫回cache也是…..
編譯器的效率也是問題,雖然Intel很有經驗,
但是這比shader compiler要複雜多了.
>>它都是用舊遊戲推測, 並沒考慮到DX11的TS unit
>和DX10的GS的影響….
>這有點像拿Xbox1的遊戲來推測X360遊戲的workload.
>不用太認真去看數字….
JIT compiler主要的用處是為了code re-use….所以它只要衝到某個performance rate之後，就不會一直再recompile，這應該是為了software rasterizer的效率，這代表developer應該可以對這個rasterizer進行customize，所以才會出現變動。
Larrabee它本身就可以靠customize來應付workload，反正只要16核心配固定寬度的ring bus、加上特定數量的TMU，後面大概都不太會改了；反倒是GPU要每一兩代去修改結構去適應API的修改，所以現在Larrabee幾個問題其實剩下
1. LNI是不是真的有那個thoughtput、還有Larrabee每個核心到底有多大，這關係到它們的效率是不是會在製程優勢加下去，此消彼長之後還超過靠TSMC的製程做出來的GPU asic pipeline。
2. TMU是Larrabee剩下唯一的fix function logic，這環本身還是有出槌的可能。
————————–
> vpu指令延遲是非一致的!! 有的高達8 clock–可能是fuse-muladd指令?
latency 不等於 指令執行間隔，那個8clock顯然是前面gather & scatter之類前置處理需要的時間，在pipeline化之後性能還是會很高。
> 另外texture cache只有節省頻寬的用途, 而無法隱蔽延遲.
所有的GPU所內建的texture cache都是為了interpolation用途(texture filter)上節省頻寬用的，沒有人拿texture cache來隱蔽延遲。
你中GPU FGMT的毒太深了….XD
GPU的FGMT只對shader like的工作有效，Larrabee是打算把高throughtput的通用處理和GPU用途一起處理掉的，所以拿cache模擬FGMT。
所以SMT當然是x86自己的register resource….
請記住，Larrabee的”GPU part”除了TMU之外全部是個microOS上的software rasterizer，只是這個rasterizer所需的大部分常用指令在Larrabee的新指令集中有實作加速，來提高效率，所以包含fiber在內的FGMT thread交換全部都是軟體行為。Larrabee在和GPU的asic群在性能上對抗的方式，在結構面只有靠指令集、以及回復單純化的core(in-order、dual-issue、4way SMT)省下的電晶體，剩下的就全部是靠製程優勢了。
>>它都是用舊遊戲推測, 並沒考慮到DX11的TS unit
>和DX10的GS的影響….
>這有點像拿Xbox1的遊戲來推測X360遊戲的workload.
>不用太認真去看數字….
JIT compiler主要的用處是為了code re-use….所以它只要衝到某個performance rate之後，就不會一直再recompile，這應該是為了software rasterizer的效率，這代表developer應該可以對這個rasterizer進行customize，所以才會出現變動。
Larrabee它本身就可以靠customize來應付workload，反正只要16核心配固定寬度的ring bus、加上特定數量的TMU，後面大概都不太會改了；反倒是GPU要每一兩代去修改結構去適應API的修改，所以現在Larrabee幾個問題其實剩下
1. LNI是不是真的有那個thoughtput、還有Larrabee每個核心到底有多大，這關係到它們的效率是不是會在製程優勢加下去，此消彼長之後還超過靠TSMC的製程做出來的GPU asic pipeline。
2. TMU是Larrabee剩下唯一的fix function logic，這環本身還是有出槌的可能。
————————–
> vpu指令延遲是非一致的!! 有的高達8 clock–可能是fuse-muladd指令?
latency 不等於 指令執行間隔，那個8clock顯然是前面gather & scatter之類前置處理需要的時間，在pipeline化之後性能還是會很高。
> 另外texture cache只有節省頻寬的用途, 而無法隱蔽延遲.
所有的GPU所內建的texture cache都是為了interpolation用途(texture filter)上節省頻寬用的，沒有人拿texture cache來隱蔽延遲。
你中GPU FGMT的毒太深了….XD
GPU的FGMT只對shader like的工作有效，Larrabee是打算把高throughtput的通用處理和GPU用途一起處理掉的，所以拿cache模擬FGMT。
所以SMT當然是x86自己的register resource….
請記住，Larrabee的”GPU part”除了TMU之外全部是個microOS上的software rasterizer，只是這個rasterizer所需的大部分常用指令在Larrabee的新指令集中有實作加速，來提高效率，所以包含fiber在內的FGMT thread交換全部都是軟體行為。Larrabee在和GPU的asic群在性能上對抗的方式，在結構面只有靠指令集、以及回復單純化的core(in-order、dual-issue、4way SMT)省下的電晶體，剩下的就全部是靠製程優勢了。
>類似shader那樣,在程式啟動前做compile.
JIT的含義還是比較清楚的. 傳統CPU-GPU也是JIT編譯shader. 是你開始沒有見過JIT而有點新想法吧?
后面Eji解釋的比較好.
>它有4組SMT thread,都是執行前compile好,
>一個thread包含ABCD…很多個GPU工作.
>ABCD…就是fiber.
>一但遇到tex指令時,由於預期會有很長的latency,
>compiler事先就插入特定的指令,告訴vector unit,
>現在從thread的工作A跳到工作B.
>把工作A的register內的東西save到cache.
>從cache把工作B的資料restore調回register.
>由於cache很大,理論上可以有很多fiber.
>但問題還是在於效率,這還未知.
>畢竟那是用軟體做的thread,要解決的問題很多,
>如果fiber用的register太多,register不夠無法
>在vector register事先放下一個fiber.
>那切換fiber就必須從cache讀進來,恐怕會損失效能.
>必須把上一個fiber寫回cache也是…..
理論上說一個HW threads里的多個fibers其實就是一個程式, 該程式含有很多互相jump的小function(就是fiber), 而live reg寄存器的保護是用push/pop類型指令來實現的(GPU 是線程之王”thread king”,硬件跳轉硬件保護reg,效率要高得多), 隨著fiber數量增加,larrabee為了保護live reg所付出的額外開銷overhead會很大的, 尤其是fiber數量很多的時候. 所以fibers數量很少–2到10個/HW thread.
而吸收延遲又需要大量的fibers才行, larrabee要糗大了.
fiber太多,額外的push/pop也會太多, fiber少了又難以吸收延遲.
關于編譯器開銷, 是會更大, 但是實際影響就難說了, 使用合適的JIT策略, 對run time繪圖性能應該無明顯影響.
>Larrabee它本身就可以靠customize來應付workload，反正只要16核心配固定寬度的ring bus、加上特定數量的TMU，後面大概都不太會改了；
fix功能的ROP等等, 是customize化的, 調用lib. 也應該沒有依靠超多fibers,或許就一個fiber/HW thread.
shader的workload是靠fiber來解決.
同意Eji關于vpu isa的看法: larrabee可能僅僅公開少數isa–HPC都要用到的核心isa/shader isa里面最常用的幾條. 因為沒有別人寫larrabee的shader編譯器, 而fix function是調用lib的. 還有很多isa,是沒有后代相容保證的,就無法公布了.
>latency 不等於 指令執行間隔，那個8clock顯然是前面gather & scatter之類前置處理需要的時間，在pipeline化之後性能還是會很高。
顯然是說GTX280的指令延遲是一致的4cycles. 而larrabee是非一致的, 什么是指非一致?例如: 有的指令延遲是2,有的是1，有的是4，有的是8.
你誤讀了”非一致”的含義.
dependent條件下的 指令執行間隔 — 延遲lateency
independent條件下的 指令執行間隔 — 吞吐
要是說那個gather & scatter之類的話,應該是much less then 16-clock. 可以看原文跨越16個cache line時候的情況.
一般而言, 談指令latency是忽視cache干擾條件下的latency. 所以說,應該是某個計算指令的延遲是8clock. 是哪一個呢？ 要猜了.
>GPU的FGMT只對shader like的工作有效，Larrabee是打算把高throughtput的通用處理和GPU用途一起處理掉的，所以拿cache模擬FGMT。
>所以SMT當然是x86自己的register resource….
應該是用軟體/指令來模擬FGMT多線程, 但是有個副作用–需要手動保護live reg, 結果cache也被消耗大量.
由于軟體模擬FGMT,導致了必然需要cache.
SMT必須要有x86 reg的4份copy. 問題是你以前對vpu reg的看法–你認為thread甚至是fiber都需要自己的vpu reg copy.
而現在看來,有可能是,應該說至少有相當數量的vpu reg是全局Global reg. 如果vector reg全都是Global reg的話? HPC的時候openmp又很難使用了. 所以也有可能是, 一部分vector reg是有thread copy的.
>反倒是GPU要每一兩代去修改結構去適應API的修改，所以現在Larrabee幾個問題其實剩下
>1. LNI是不是真的有那個thoughtput、還有Larrabee每個核心到底有多大，這關係到它們的效率是不是會在製程優勢加下去，此消彼長之後還超過靠TSMC的製程做出來的GPU asic pipeline。
>2. TMU是Larrabee剩下唯一的fix function logic，這環本身還是有出槌的可能。
如果larrabee僅能達到1GHz,或10個核心以內,那就太沒有競爭力了！
TMU本身的設計應該是花了很大精力與很多資源,看它使用32KB的texture cache就應該看出有多大的投入了. 或許larrabee其他都很低效,就是 剩下TMU本身還算合格.
> Larrabee在和GPU的asic群在性能上對抗的方式，在結構面只有靠指令集、以及回復單純化的core(in-order、dual-issue、4way SMT)省下的電晶體，剩下的就全部是靠製程優勢了。
如果是nvidia設計了并委托代工廠生產了larrabee (但x86那部分被shader isa取代), 你認為其性能會如何呢？ 是會輸給GTX280 很多很多?
>類似shader那樣,在程式啟動前做compile.
JIT的含義還是比較清楚的. 傳統CPU-GPU也是JIT編譯shader. 是你開始沒有見過JIT而有點新想法吧?
后面Eji解釋的比較好.
>它有4組SMT thread,都是執行前compile好,
>一個thread包含ABCD…很多個GPU工作.
>ABCD…就是fiber.
>一但遇到tex指令時,由於預期會有很長的latency,
>compiler事先就插入特定的指令,告訴vector unit,
>現在從thread的工作A跳到工作B.
>把工作A的register內的東西save到cache.
>從cache把工作B的資料restore調回register.
>由於cache很大,理論上可以有很多fiber.
>但問題還是在於效率,這還未知.
>畢竟那是用軟體做的thread,要解決的問題很多,
>如果fiber用的register太多,register不夠無法
>在vector register事先放下一個fiber.
>那切換fiber就必須從cache讀進來,恐怕會損失效能.
>必須把上一個fiber寫回cache也是…..
理論上說一個HW threads里的多個fibers其實就是一個程式, 該程式含有很多互相jump的小function(就是fiber), 而live reg寄存器的保護是用push/pop類型指令來實現的(GPU 是線程之王”thread king”,硬件跳轉硬件保護reg,效率要高得多), 隨著fiber數量增加,larrabee為了保護live reg所付出的額外開銷overhead會很大的, 尤其是fiber數量很多的時候. 所以fibers數量很少–2到10個/HW thread.
而吸收延遲又需要大量的fibers才行, larrabee要糗大了.
fiber太多,額外的push/pop也會太多, fiber少了又難以吸收延遲.
關于編譯器開銷, 是會更大, 但是實際影響就難說了, 使用合適的JIT策略, 對run time繪圖性能應該無明顯影響.
>Larrabee它本身就可以靠customize來應付workload，反正只要16核心配固定寬度的ring bus、加上特定數量的TMU，後面大概都不太會改了；
fix功能的ROP等等, 是customize化的, 調用lib. 也應該沒有依靠超多fibers,或許就一個fiber/HW thread.
shader的workload是靠fiber來解決.
同意Eji關于vpu isa的看法: larrabee可能僅僅公開少數isa–HPC都要用到的核心isa/shader isa里面最常用的幾條. 因為沒有別人寫larrabee的shader編譯器, 而fix function是調用lib的. 還有很多isa,是沒有后代相容保證的,就無法公布了.
>latency 不等於 指令執行間隔，那個8clock顯然是前面gather & scatter之類前置處理需要的時間，在pipeline化之後性能還是會很高。
顯然是說GTX280的指令延遲是一致的4cycles. 而larrabee是非一致的, 什么是指非一致?例如: 有的指令延遲是2,有的是1，有的是4，有的是8.
你誤讀了”非一致”的含義.
dependent條件下的 指令執行間隔 — 延遲lateency
independent條件下的 指令執行間隔 — 吞吐
要是說那個gather & scatter之類的話,應該是much less then 16-clock. 可以看原文跨越16個cache line時候的情況.
一般而言, 談指令latency是忽視cache干擾條件下的latency. 所以說,應該是某個計算指令的延遲是8clock. 是哪一個呢？ 要猜了.
>GPU的FGMT只對shader like的工作有效，Larrabee是打算把高throughtput的通用處理和GPU用途一起處理掉的，所以拿cache模擬FGMT。
>所以SMT當然是x86自己的register resource….
應該是用軟體/指令來模擬FGMT多線程, 但是有個副作用–需要手動保護live reg, 結果cache也被消耗大量.
由于軟體模擬FGMT,導致了必然需要cache.
SMT必須要有x86 reg的4份copy. 問題是你以前對vpu reg的看法–你認為thread甚至是fiber都需要自己的vpu reg copy.
而現在看來,有可能是,應該說至少有相當數量的vpu reg是全局Global reg. 如果vector reg全都是Global reg的話? HPC的時候openmp又很難使用了. 所以也有可能是, 一部分vector reg是有thread copy的.
>反倒是GPU要每一兩代去修改結構去適應API的修改，所以現在Larrabee幾個問題其實剩下
>1. LNI是不是真的有那個thoughtput、還有Larrabee每個核心到底有多大，這關係到它們的效率是不是會在製程優勢加下去，此消彼長之後還超過靠TSMC的製程做出來的GPU asic pipeline。
>2. TMU是Larrabee剩下唯一的fix function logic，這環本身還是有出槌的可能。
如果larrabee僅能達到1GHz,或10個核心以內,那就太沒有競爭力了！
TMU本身的設計應該是花了很大精力與很多資源,看它使用32KB的texture cache就應該看出有多大的投入了. 或許larrabee其他都很低效,就是 剩下TMU本身還算合格.
> Larrabee在和GPU的asic群在性能上對抗的方式，在結構面只有靠指令集、以及回復單純化的core(in-order、dual-issue、4way SMT)省下的電晶體，剩下的就全部是靠製程優勢了。
如果是nvidia設計了并委托代工廠生產了larrabee (但x86那部分被shader isa取代), 你認為其性能會如何呢？ 是會輸給GTX280 很多很多?
> 如果larrabee僅能達到1GHz,或10個核心以內,那就太沒有競爭力了！
>TMU本身的設計應該是花了很大精力與很多資源,看它使用32KB的texture cache就應該看出有多大的投入了. 或許larrabee其他都很低效,就是 剩下TMU本身還算合格.
他實際的產品顯然不會是這樣，所以我覺得這不是很有意義的討論：你不能假設Intel 只做個和你一樣規格的CPU，然後和你拼效率：他是個製造導向的廠商，Larrabee的作用是把x86延伸到stream processing，讓這個範疇的programming style”也不願意port到GPU的方向”，就可以截斷N/A等GPU廠商的成長空間。
> 如果是nvidia設計了并委托代工廠生產了larrabee (但x86那部分被shader isa取代), 你認為其性能會如何呢？ 是會輸給GTX280 很多很多?
這其實就是在問「如果”(除了TMU外)GPU所有的功能都由shader執行”的話，那同性能的GPU規模要膨脹多大，才能在”現有的application上”符合目前的效率？」這個問題啦。
> 如果larrabee僅能達到1GHz,或10個核心以內,那就太沒有競爭力了！
>TMU本身的設計應該是花了很大精力與很多資源,看它使用32KB的texture cache就應該看出有多大的投入了. 或許larrabee其他都很低效,就是 剩下TMU本身還算合格.
他實際的產品顯然不會是這樣，所以我覺得這不是很有意義的討論：你不能假設Intel 只做個和你一樣規格的CPU，然後和你拼效率：他是個製造導向的廠商，Larrabee的作用是把x86延伸到stream processing，讓這個範疇的programming style”也不願意port到GPU的方向”，就可以截斷N/A等GPU廠商的成長空間。
> 如果是nvidia設計了并委托代工廠生產了larrabee (但x86那部分被shader isa取代), 你認為其性能會如何呢？ 是會輸給GTX280 很多很多?
這其實就是在問「如果”(除了TMU外)GPU所有的功能都由shader執行”的話，那同性能的GPU規模要膨脹多大，才能在”現有的application上”符合目前的效率？」這個問題啦。
>他實際的產品顯然不會是這樣，所以我覺得這不是很有意義的討論：你不能假設Intel 只做個和你一樣規格的CPU，然後和你拼效率：他是個製造導向的廠商，Larrabee的作用是把x86延伸到stream processing，讓這個範疇的programming style”也不願意port到GPU的方向”，就可以截斷N/A等GPU廠商的成長空間。
覺得x86是假的,是真的想進攻GPU. 看他如何設計vpu reg的SMT, 要是從CPU的角度看, vpu reg是有很大問題的. 如果將來引入HW ROP與HW fiber. 那就是純種GPU了.
>這其實就是在問「如果”(除了TMU外)GPU所有的功能都由shader執行”的話，那同性能的GPU規模要膨脹多大，才能在”現有的application上”符合目前的效率？」這個問題啦。
當然是另外一個問題啦. 是問就按larrabee的架構(除了x86用shader isa代替以外). 你認為要是nvidia來做,那和GTX280的差距如何呢？
而非問nvidia設計一個基于shader isa的全軟體化的GPU(與larrabee架構可以無關).
軟體化是大方向, 但是以shader isa為基礎的全軟體化,才是正確的方向. x86是個包袱.
>他實際的產品顯然不會是這樣，所以我覺得這不是很有意義的討論：你不能假設Intel 只做個和你一樣規格的CPU，然後和你拼效率：他是個製造導向的廠商，Larrabee的作用是把x86延伸到stream processing，讓這個範疇的programming style”也不願意port到GPU的方向”，就可以截斷N/A等GPU廠商的成長空間。
覺得x86是假的,是真的想進攻GPU. 看他如何設計vpu reg的SMT, 要是從CPU的角度看, vpu reg是有很大問題的. 如果將來引入HW ROP與HW fiber. 那就是純種GPU了.
>這其實就是在問「如果”(除了TMU外)GPU所有的功能都由shader執行”的話，那同性能的GPU規模要膨脹多大，才能在”現有的application上”符合目前的效率？」這個問題啦。
當然是另外一個問題啦. 是問就按larrabee的架構(除了x86用shader isa代替以外). 你認為要是nvidia來做,那和GTX280的差距如何呢？
而非問nvidia設計一個基于shader isa的全軟體化的GPU(與larrabee架構可以無關).
軟體化是大方向, 但是以shader isa為基礎的全軟體化,才是正確的方向. x86是個包袱.
> 覺得x86是假的,是真的想進攻GPU. 看他如何設計vpu reg的SMT, 要是從CPU的角度看, vpu reg是有很大問題的. 如果將來引入HW ROP與HW fiber. 那就是純種GPU了.
他何必進攻GPU？ 是GPU進犯到他的獲利範圍，所以它要把CPU趕出去….也沒人規定它現在這樣”不是純種GPU”，我認為既然有TMU、是一張獨立add-in-card的話，就仍然算是純種的GPU，因為目前GPU的商業型態還在獨立介面卡的買賣上，所以只要是介面卡、user買了裝driver之後可以跑遊戲和應用軟體，就算是GPU(或者是”顯示卡、繪圖卡”)。
>軟體化是大方向, 但是以shader isa為基礎的全軟體化,才是正確的方向. x86是個包袱.
我很贊同x86這個東西是包袱，x86的包袱不是幾年而已，是幾十年了….但是有太多經驗告訴我們，這包袱同時也是門票。
所以我不認為shader isa or x86 isa是個很大的問題，因為手上沒有x86 isa的廠商，沒有哪個可以和Intel比製程，甚至連intel自己想放掉x86 ISA的努力也不斷地失敗….所以這是市場現實，很多人都覺得Larrabee不必引入x86 ISA、但是今天Intel自己都些適合GPU的ISA(比方說IA-64就不錯)，但是他們現在的決策核心顯然是認為要打PC市場的產品現在沒有x86就不能長久….而且他們的many-core的核心概念，有一點很重要就是統一ISA，然後各種不同特性的核心並存、並且以compiler去針對各種不同特性的核心產生需要的code。
所以x86是個包袱沒錯，但是撐不起這個包袱的人，只能做”非CPU的approach”，結果就是又被Intel拿CPU來挑戰….
要打破這個循環，大概只有哪個強者搞出一個比Intel製程還強大的組織，不然大概會一直重現這個歷史。
> 覺得x86是假的,是真的想進攻GPU. 看他如何設計vpu reg的SMT, 要是從CPU的角度看, vpu reg是有很大問題的. 如果將來引入HW ROP與HW fiber. 那就是純種GPU了.
他何必進攻GPU？ 是GPU進犯到他的獲利範圍，所以它要把CPU趕出去….也沒人規定它現在這樣”不是純種GPU”，我認為既然有TMU、是一張獨立add-in-card的話，就仍然算是純種的GPU，因為目前GPU的商業型態還在獨立介面卡的買賣上，所以只要是介面卡、user買了裝driver之後可以跑遊戲和應用軟體，就算是GPU(或者是”顯示卡、繪圖卡”)。
>軟體化是大方向, 但是以shader isa為基礎的全軟體化,才是正確的方向. x86是個包袱.
我很贊同x86這個東西是包袱，x86的包袱不是幾年而已，是幾十年了….但是有太多經驗告訴我們，這包袱同時也是門票。
所以我不認為shader isa or x86 isa是個很大的問題，因為手上沒有x86 isa的廠商，沒有哪個可以和Intel比製程，甚至連intel自己想放掉x86 ISA的努力也不斷地失敗….所以這是市場現實，很多人都覺得Larrabee不必引入x86 ISA、但是今天Intel自己都些適合GPU的ISA(比方說IA-64就不錯)，但是他們現在的決策核心顯然是認為要打PC市場的產品現在沒有x86就不能長久….而且他們的many-core的核心概念，有一點很重要就是統一ISA，然後各種不同特性的核心並存、並且以compiler去針對各種不同特性的核心產生需要的code。
所以x86是個包袱沒錯，但是撐不起這個包袱的人，只能做”非CPU的approach”，結果就是又被Intel拿CPU來挑戰….
要打破這個循環，大概只有哪個強者搞出一個比Intel製程還強大的組織，不然大概會一直重現這個歷史。
以前和你說過晶圓廠的成本增加速度遠遠超過CPU市場容量的提升，據說建一個450mm晶圓廠要耗費百億$. 像GPU如此單一的市場,而且是有希望成長到高達百億$/年, 是它下手的最佳目標. GPU的市場終于在GPU廠商的多年打拼下成長到如此之大。有個強權因為自身市場成長太慢而晶圓廠成本提高太快而要出手搶奪nvidia多年經營的勝利果實了.
以務實的角度說, nvidia應該把GPU繪圖性能提高到足以輕易摧毀任何CPU入侵企圖的地步, 千萬別上當在通用計算上浪費資源. 應該先防守后進攻. 要說一套做一套, 表面說要讓GPU去侵略CPU領地,其實行動是重兵把守GPU領地. 要是真的向通用計算方向耗費太多資源, 那要吃大虧的.
larrabee是進攻者. 要先把先頭部隊給扁死!!
以前和你說過晶圓廠的成本增加速度遠遠超過CPU市場容量的提升，據說建一個450mm晶圓廠要耗費百億$. 像GPU如此單一的市場,而且是有希望成長到高達百億$/年, 是它下手的最佳目標. GPU的市場終于在GPU廠商的多年打拼下成長到如此之大。有個強權因為自身市場成長太慢而晶圓廠成本提高太快而要出手搶奪nvidia多年經營的勝利果實了.
以務實的角度說, nvidia應該把GPU繪圖性能提高到足以輕易摧毀任何CPU入侵企圖的地步, 千萬別上當在通用計算上浪費資源. 應該先防守后進攻. 要說一套做一套, 表面說要讓GPU去侵略CPU領地,其實行動是重兵把守GPU領地. 要是真的向通用計算方向耗費太多資源, 那要吃大虧的.
larrabee是進攻者. 要先把先頭部隊給扁死!!
例如:
http://ati.amd.com/…r/cgo/2008/Rubin-CGO2008.pdf
有一頁，對CPU與GPU的定位與特性,說的很好.
感覺是, 頭腦發熱是無用的, 架構上的重大區別, 決定了通用軟體更適合在CPU上執行. 而相容性壁壘將徹底破滅進攻CPU的企圖.
讓人擔心的是, larrabee是偽CPU真GPU, 如果就是CPU, 就沒有什么好怕的了. 就怕強權是想霸占別人的多年勞動果實. 就算性能差,到時候還會借助”平臺化”戰略來行銷獨立顯卡等市場手段, 搞惡性競爭, 以劣品驅逐良品.
例如:
http://ati.amd.com/…r/cgo/2008/Rubin-CGO2008.pdf
有一頁，對CPU與GPU的定位與特性,說的很好.
感覺是, 頭腦發熱是無用的, 架構上的重大區別, 決定了通用軟體更適合在CPU上執行. 而相容性壁壘將徹底破滅進攻CPU的企圖.
讓人擔心的是, larrabee是偽CPU真GPU, 如果就是CPU, 就沒有什么好怕的了. 就怕強權是想霸占別人的多年勞動果實. 就算性能差,到時候還會借助”平臺化”戰略來行銷獨立顯卡等市場手段, 搞惡性競爭, 以劣品驅逐良品.