Re: [問題] Bit數
※ 引述《FiveAaaa ([5A]aaa)》之銘言：
: ※ 引述《maply0703 (落葉)》之銘言：
: : 傳輸頻寬
: : 記憶體時脈每跳動一次時
: : 所傳輸的位元數量
: : 例如記憶體時脈400MHZ
: 此處提到了記憶體時脈, 那核心時脈又有什麼影響呢?
: 是指: 用 [ (記憶體時脈) * (傳輸頻寬) ] bps傳入GPU, GPU再用xxxMHz來運算嗎?
: 謝謝!
小弟剛好是做GPU的..來大概簡述一下好了~
不過我是寫drvier跟demo的..所以會比較以軟體的角度來想~
名詞解釋:
視訊記憶體(VRAM)=>也就是顯示卡所標榜的記憶體
系統記憶體(System RAM)=>也就是平常所說的記憶體
GPU=>就是繪圖顯示晶片, 7300GT, 7600GT這類的東西.
大致上流程是這樣的:
1. 傳統:
3D應用程式透過API將節點資料跟效果設定從System Memory送進VRAM
Shader:
3D應用程式透過Shader program將資料(包含程式)從System Memory送進VRAM
這是第一個傳送瓶頸:system memory->vram,
最大值限制為PCI/AGP/PCI-E所能承受的頻寬.
2. 上面的步驟是將系統記憶體資料跟命令送進command queue,
command queue是什麼呢? 從頭解釋的話太麻煩, 就簡述吧!
當驅動程式下命令給硬體的時候, 硬體是不能做其他事情的,
這一點跟CPU跟OS的關係是一樣的, 所以這時候如果有一個buffer,
把要給硬體的命令存起來 每隔一段時間發一次給硬體,
其他的時間就可以給硬體去做其他事情, 而不會被傳送這些命令佔住時間.
而這些給硬體的命令中, 有很多時候會是送節點資料給硬體的,
這個時候這個機制就很重要了,
如果沒有這個機制的話, 驅動程式跟硬體說,
現在開始從某記憶體位置開始搬資料到VRAM去,
而假設資料很多, 搬動資料需要100毫秒, 那麼這100毫秒就沒辦法做3D運算,
所以FPS就會被限制在10fps以下,
如果有這個機制的話, 那麼驅動程式只要跟硬體說"搬資料囉!"
然後就不用管硬體搬資料搬到哪, 而可以繼續做之前沒做完的3D運算,
而不用等硬體搬資料.
這個道理跟最近新興的硬碟NCQ原理是一樣的,
不過這個機制在顯示卡上已經行之有年了~
command queue就是這個buffer, 而這時候引擎&記憶體的時脈就開始有影響了:
GPU這時候會從VRAM command queue部分parse資料, 然後做運算,
送到frame buffer去(frame buffer定義請查google, 因為很基本)
這裡就扯到VRAM跟GPU時脈的關係了, VRAM送的快, GPU就收的多,
能處理的3D指令也就多, 速度也就越快, 如果VRAM太慢, 那麼資料送不夠快,
那麼引擎工作當然也快不起來, 會有很多時間閒置.
如果VRAM夠快, GPU卻不夠快, 那麼GPU就會卡住效能.
3. GPU畫完之後, 如果非全螢幕的話, 通常會將framebuffer放在一個看不見的buffer,
然後在將buffer打到window內, 這部分就跟vram有很大的關係了,
因為這是一個gpu->vram->vram copy的動作,
這個部分記憶體時脈就直接影響到所謂的Fill Rate (像素填充率)
假設GPU能力可以負荷到每秒一億個點, 但是記憶體卻沒辦法跟上,
那麼Fill Rate就會被卡VRAM那端.
如果vram每秒有效時脈是400Mhz, 那麼一秒鐘就可以搬4億次資料,
假設記憶體寬度是128bit, 那麼一秒就是51200000000bps,
約6GB/s,如果畫面是32bit RGBA的話, 那麼fill rate就是1.5 Billion pixel/sec.
注意, 這是以vram的速度來判斷的, 並不是GPU時脈去算,
假設GPU時脈560Mhz, 256bit, 那麼一秒可運算的資料量就是:
560000000*256bit/32bit=>fill rate = 4.48Billion pixel/sec,
而全螢幕的時候不需要做搬動的動作, 因為不需考慮視窗重疊的狀況,
所以實際能力可以加倍, 將資料搬移簡化到單純一次gpu->vram,
所以在16bit色彩理想狀態可達到9 billion pixel/sec, 扣掉GPU自己的耗時,
就是實際的fill rate.
(這是假設沒有interrupt發生或者其他因素的理想狀態, 實際不大可能達到XD)
也有些廠商會用32bit當spec, 但是會做一些加成, 或者特殊的"偷吃步",
來省時間以達到一些漂亮的數字, 也就是犧牲品質換取速率.
也就是說, 就算GPU可以做到這麼快, 但是如果VRAM衝不到這麼快,
則像素填充率就會被限制在VRAM上, 這也就是為什麼超頻記憶體會有用的原因之一.
上面我是拿7600GT當範例, 但是7600GT spec寫的是6.7 billion pixel/sec?
這部分是因為command會有一些overhead,
並不是所有的時脈都可以全部拿來做填充的動作.(就是上面提的gpu自己的耗時)
至於為什麼我會拿400Mhz而不是拿ddr的800Mhz來說呢?
因為, GPU跟VRAM溝通是需要做hand-shaking的,而記憶體本身也會有些延遲,
hand-shaking這個動作就是在做: GPU發命令跟記憶體說"我要送資料了"
接著等一小段時間, 可能是1個tick, 也可能會慢到3~4個tick,
接著記憶體會回"ok我可以收", 然後又會等1~3個tick去等GPU發資料,
所以說這些頻寬能力並不是直接拿來乘就好,
實際頻寬還是需要除掉這些hand-shaking的時間的,
在這裡我用了比較低的數據去估計, 畢竟我不知道各廠商的記憶體設定:p
所以說, 記憶體寬度決定了視訊記憶體是否會成為GPU瓶頸,
但是或許有人會說, 照這樣算起來, 7900GTX的記憶體根本也達不到需要的頻寬!?
沒錯, 因為事實上根本沒必要讓記憶體完全跟上GPU,
透過OpenGL/Direct3D這些API, 可以事先把資料送進VRAM,
然後之後就不在需要每個frame都送一次資料, 這部分就相當的省時了,
這使得傳輸的資料可以簡化到大部分都是送硬體命令,
省下了最佔時間的資料傳輸時間.
這個時候, game跟game engine設計好壞就可以一分高下了,
好的引擎跟遊戲設計規劃可以省下許多不必要的資料傳輸,
對於vram頻寬的需求相對就減少許多,
EA Games就是這方面我認為最強的專家,
而這也是為什麼有些廠商的遊戲竟然普通的效果就要很高的硬體,
有些廠商的遊戲居然可以用低硬體要求究可以做到更好的效果的原因.
至於polygon rate又是另一個故事了....0rz 就不提啦XD
所以呢..我一直覺得買最好的顯示卡是阻礙那些爛遊戲引擎發展的元兇阿XD
但是也有時候遊戲程式寫的爛但是把時間花在遊戲內容上的話
我還是會覺得很值得就是了...真兩難阿QQ
: : 傳輸頻寬64BIT
: : 傳輸速度就是
: : 400*64/8(/8是bit轉換成byte)=3200MB/sec
: : 如果時脈相同，bit變成128bit
: : 400*128/8=6400MB/sec
: : 直接變成兩倍
: : 所以bit數是相當重要的喔!
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.135.88.74
推
11/06 11:50, , 1F
11/06 11:50, 1F
推
11/06 11:50, , 2F
11/06 11:50, 2F
推
11/06 11:52, , 3F
11/06 11:52, 3F
推
11/06 12:10, , 4F
11/06 12:10, 4F
推
11/06 12:13, , 5F
11/06 12:13, 5F
→
11/06 12:16, , 6F
11/06 12:16, 6F
推
11/06 12:18, , 7F
11/06 12:18, 7F
推
11/06 12:20, , 8F
11/06 12:20, 8F
推
11/06 12:20, , 9F
11/06 12:20, 9F
→
11/06 12:20, , 10F
11/06 12:20, 10F
→
11/06 12:20, , 11F
11/06 12:20, 11F
推
11/06 12:32, , 12F
11/06 12:32, 12F
推
11/06 12:41, , 13F
11/06 12:41, 13F
推
11/06 12:45, , 14F
11/06 12:45, 14F
推
11/06 13:02, , 15F
11/06 13:02, 15F
推
11/06 13:12, , 16F
11/06 13:12, 16F
推
11/06 13:29, , 17F
11/06 13:29, 17F
推
11/06 13:30, , 18F
11/06 13:30, 18F
推
11/06 13:38, , 19F
11/06 13:38, 19F
→
11/06 13:38, , 20F
11/06 13:38, 20F
※ 編輯: alvinli 來自: 220.135.88.74 (11/06 13:39)
→
11/06 13:39, , 21F
11/06 13:39, 21F
※ 編輯: alvinli 來自: 220.135.88.74 (11/06 13:48)
推
11/06 14:10, , 22F
11/06 14:10, 22F
推
11/06 15:48, , 23F
11/06 15:48, 23F
推
11/06 15:55, , 24F
11/06 15:55, 24F
推
11/06 15:58, , 25F
11/06 15:58, 25F
※ 編輯: alvinli 來自: 220.135.88.74 (11/06 16:05)
推
11/06 16:05, , 26F
11/06 16:05, 26F
→
11/06 16:06, , 27F
11/06 16:06, 27F
推
11/06 16:41, , 28F
11/06 16:41, 28F
推
11/06 16:57, , 29F
11/06 16:57, 29F
推
11/06 17:09, , 30F
11/06 17:09, 30F
推
11/06 17:26, , 31F
11/06 17:26, 31F
推
11/06 17:40, , 32F
11/06 17:40, 32F
推
11/06 17:58, , 33F
11/06 17:58, 33F
推
11/06 18:03, , 34F
11/06 18:03, 34F
推
11/06 18:15, , 35F
11/06 18:15, 35F
推
11/06 18:42, , 36F
11/06 18:42, 36F
推
11/06 19:22, , 37F
11/06 19:22, 37F
推
11/06 20:19, , 38F
11/06 20:19, 38F
推
11/06 20:23, , 39F
11/06 20:23, 39F
推
11/06 20:23, , 40F
11/06 20:23, 40F
推
11/06 20:44, , 41F
11/06 20:44, 41F
推
11/06 20:47, , 42F
11/06 20:47, 42F
推
11/06 20:53, , 43F
11/06 20:53, 43F
推
11/06 22:18, , 44F
11/06 22:18, 44F
推
11/06 22:56, , 45F
11/06 22:56, 45F
推
11/06 23:16, , 46F
11/06 23:16, 46F
→
11/06 23:17, , 47F
11/06 23:17, 47F
推
11/07 01:04, , 48F
11/07 01:04, 48F
推
11/07 02:08, , 49F
11/07 02:08, 49F
推
11/07 02:26, , 50F
11/07 02:26, 50F
推
11/07 03:56, , 51F
11/07 03:56, 51F
推
11/07 09:27, , 52F
11/07 09:27, 52F
推
11/07 18:24, , 53F
11/07 18:24, 53F
討論串 (同標題文章)
VideoCard 近期熱門文章
PTT數位生活區 即時熱門文章
