Re: [閒聊] 有沒有L1 L2成本的八卦
※ 引述《herculex (漂流木)》之銘言:
: 唔...這是認真的
: 看到GT300中出現L1 L2這是不是意味著GT300設計越來越像CPU
: 只不過印象中L1成本很高 L2成本稍低
: 不曉得這樣的認知有沒有錯
: GT220據說是以GT200架構為基礎,那是不是在中低階上這樣的方案就不容易延用?
: GT300上有16組Streaming Multiprocessor 每組SM有16KB的L1 768KB的L2
: 所以總計有256KB的L1 12MB的L2 這樣算沒錯吧@@
: 這樣的架構在產品定位的延伸性會不會受影響
GT200/G9x/G8x 每個SMp(Block)中含有16KB的.......
Local Memory (O)
Embedded Memory (O)
Cache (X)
Software Cache(片笑...)
GT300則進一步擴展成64KB,可以有兩種組態的
Scratchpad Memory (O)
Scratchpad cache (O)
cache (X)
應該說每個SMp底下有64KB,可以16KB cache,48KB手動控制的記憶體.
或者是48KB cache,16KB手動控制的記憶體.
其中之所以不能全部當cache用,可能是為了保障相容性.
否則無法執行以往G80/GT200的舊程式.....這部分其實還很不明確.
兩者都是在晶片內部,以高速SRAM實作的記憶體.不過
scratchpad memory和cache的差別則在於:
1. cache是自動操作 ,sratchpad memory要讀寫甚麼資料都是由程式手動
2. cache的好處在於才剛讀寫過的資料保存,但是在比如streaming資料的場合.
比如說影音資料等持續送來,每個只使用一次等.cache就沒有甚麼好處.
這時候能手動預先讀入的scratchpad memory才有優勢.
至於RV870也具有scratchpad memory或者是embedded memory.
(並非只有GPGPU需要.所以很顯然更早以前的DX10晶片也有只是資料不明)
只是對於cache的部分則不明.....
=============================
寫一下範例好了.假設系統有32MB主記憶體.64KB cache或者是scratchpad memory
外部記憶體存取時間100 cycle,cache/SPM存取 3 cycle.
scratchpad memory的場合:
定址空間中,有64KB必須被劃定為SPM(scatchpad memory的縮寫)佔用,
在CPU中,邏輯上可以用的記憶體容量是定址空間,但是並非都是真的可以用的記憶體,
有些會被保留住,有些被當其他用途......
0--------128KB-------192KB------1MB------------33MB
SPM Main Memory
這時候,CPU的指令如果要使用較快的SPM,就必須
讀寫128~192KB這個區段.而且也比主記憶體快很多.
所以一般而言,會先把初始資料由Main Memory區段搬入128-192這個範圍.
然後計算的過程會儘量讀寫這塊區域..最後算完了,再把結果由128-192中間
搬出來.複製回主記憶體.
這時候,讀寫SPM以及Main Memory區段不但是沒相關的兩塊,而且
Main Memory不管同一個位址連續讀幾次.都要花同樣久的時間.
如果是cache的話,cpu指令就只看的見&操作 Main Memory的32MB,
可是有一個看不見的cache在背後運作,它會保留前幾次Memory讀寫的內容,
只要用的是同樣的位址,就會直接自cache中取出(cache hit).而取得較快
的速度.如果不存在於cache中的話(cache miss),就仍然自主記憶體中讀取,
並且複製一份放在cache中等待下次用到....cache的說明我比較省略是因為
對pc玩家來說應該對cache不陌生才對.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.114.78.62
→
10/01 23:42, , 1F
10/01 23:42, 1F
→
10/01 23:43, , 2F
10/01 23:43, 2F
推
10/01 23:44, , 3F
10/01 23:44, 3F
推
10/01 23:44, , 4F
10/01 23:44, 4F
推
10/01 23:45, , 5F
10/01 23:45, 5F
推
10/01 23:46, , 6F
10/01 23:46, 6F
推
10/01 23:46, , 7F
10/01 23:46, 7F
→
10/01 23:46, , 8F
10/01 23:46, 8F
問題是速度,register隨時都可以用.沒有延遲.
cache或者是scratchpad memory可能有1~3個cycle,
DRAM memory可能在100個cycle以上.
→
10/01 23:46, , 9F
10/01 23:46, 9F
推
10/01 23:47, , 10F
10/01 23:47, 10F
推
10/01 23:47, , 11F
10/01 23:47, 11F
→
10/01 23:47, , 12F
10/01 23:47, 12F
※ 編輯: jk21234 來自: 140.114.78.62 (10/02 00:02)
推
10/01 23:48, , 13F
10/01 23:48, 13F
推
10/01 23:48, , 14F
10/01 23:48, 14F
那部分是使用GPU舊有的"texture cache"機制.
GPU很早以前就擁有少量cache,但是並沒有被太大著墨.
原因很明顯,因為圖像資料有很大的量是不會被重複用到的.
但是貼圖是另外一個問題,同一個貼圖可能被用在很多區域很多三角面上.
所以texture cache可以派上用場,但是也只要能讀就好了.
→
10/01 23:48, , 15F
10/01 23:48, 15F
→
10/01 23:48, , 16F
10/01 23:48, 16F
→
10/01 23:48, , 17F
10/01 23:48, 17F
原因很簡單啊,你沒辦法做一個又大又快又可以共享不會打架的記憶體架構.
只好切出trade-off最小的做法.
如果你需要寫一個1024x1024的矩陣運算,裡面的資料就一定不夠用了.
(至少要好幾MB,1024x1024x每筆資料長度)
這時候.....
a.給你16~64KB的小型快速記憶體,自己切割程式成塞得進去.
b.不管它,直接照直覺寫,這時候你需要做存取緩慢的主記憶體
約一百萬次.每次100個cycle
c.邏輯上直接寫,但是有cache幫你節省時間增進效率.
這個例子聽起來cache比較好對嗎 ??
不過,如果換成你要把一個圖案壓縮成jpeg/mpeg,可能就相反了.
因為最重要的是把所有的像素,以8x8或者是16x16一組分割,然後分別進行破壞性壓縮
這時候,每組資料也只會用到一次,因此cache的效果就不如手動控制了.
推
10/01 23:49, , 18F
10/01 23:49, 18F
→
10/01 23:49, , 19F
10/01 23:49, 19F
→
10/01 23:49, , 20F
10/01 23:49, 20F
→
10/01 23:49, , 21F
10/01 23:49, 21F
推
10/01 23:50, , 22F
10/01 23:50, 22F
→
10/01 23:50, , 23F
10/01 23:50, 23F
→
10/01 23:50, , 24F
10/01 23:50, 24F
推
10/01 23:50, , 25F
10/01 23:50, 25F
→
10/01 23:50, , 26F
10/01 23:50, 26F
我的看法是跟這個無關,GT300的走向非常像DSP
→
10/01 23:51, , 27F
10/01 23:51, 27F
→
10/01 23:51, , 28F
10/01 23:51, 28F
→
10/01 23:51, , 29F
10/01 23:51, 29F
x86指令集是公共財.不過如果只要做mCU的話其實沒有非要用x86不可.
→
10/01 23:51, , 30F
10/01 23:51, 30F
→
10/01 23:51, , 31F
10/01 23:51, 31F
→
10/01 23:52, , 32F
10/01 23:52, 32F
→
10/01 23:52, , 33F
10/01 23:52, 33F
還有 302 則推文
還有 4 段內文
→
10/02 00:47, , 336F
10/02 00:47, 336F
→
10/02 00:48, , 337F
10/02 00:48, 337F
推
10/02 00:48, , 338F
10/02 00:48, 338F
推
10/02 00:48, , 339F
10/02 00:48, 339F
→
10/02 00:49, , 340F
10/02 00:49, 340F
→
10/02 00:51, , 341F
10/02 00:51, 341F
→
10/02 00:51, , 342F
10/02 00:51, 342F
→
10/02 00:51, , 343F
10/02 00:51, 343F
→
10/02 00:52, , 344F
10/02 00:52, 344F
推
10/02 00:52, , 345F
10/02 00:52, 345F
→
10/02 00:52, , 346F
10/02 00:52, 346F
→
10/02 00:53, , 347F
10/02 00:53, 347F
推
10/02 00:53, , 348F
10/02 00:53, 348F
→
10/02 00:53, , 349F
10/02 00:53, 349F
推
10/02 00:54, , 350F
10/02 00:54, 350F
→
10/02 00:54, , 351F
10/02 00:54, 351F
→
10/02 00:56, , 352F
10/02 00:56, 352F
推
10/02 00:56, , 353F
10/02 00:56, 353F
推
10/02 00:57, , 354F
10/02 00:57, 354F
→
10/02 00:58, , 355F
10/02 00:58, 355F
推
10/02 00:58, , 356F
10/02 00:58, 356F
→
10/02 00:58, , 357F
10/02 00:58, 357F
→
10/02 00:59, , 358F
10/02 00:59, 358F
→
10/02 01:00, , 359F
10/02 01:00, 359F
推
10/02 01:00, , 360F
10/02 01:00, 360F
推
10/02 01:01, , 361F
10/02 01:01, 361F
推
10/02 01:01, , 362F
10/02 01:01, 362F
推
10/02 01:01, , 363F
10/02 01:01, 363F
→
10/02 01:01, , 364F
10/02 01:01, 364F
→
10/02 01:02, , 365F
10/02 01:02, 365F
推
10/02 01:03, , 366F
10/02 01:03, 366F
→
10/02 01:03, , 367F
10/02 01:03, 367F
→
10/02 01:03, , 368F
10/02 01:03, 368F
推
10/02 01:03, , 369F
10/02 01:03, 369F
推
10/02 11:44, , 370F
10/02 11:44, 370F
→
10/02 11:44, , 371F
10/02 11:44, 371F
推
10/02 12:22, , 372F
10/02 12:22, 372F
推
10/02 12:51, , 373F
10/02 12:51, 373F
推
10/02 16:18, , 374F
10/02 16:18, 374F
→
10/02 16:19, , 375F
10/02 16:19, 375F
PC_Shopping 近期熱門文章
PTT數位生活區 即時熱門文章