※ 引述《alvinli (alvin)》之銘言： : 小弟剛好是做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所能承受的頻寬. 在DX8/DX9中,vertex shader/Pixel shader是與T&L/pixel operation 併行的path. : 3. GPU畫完之後, 如果非全螢幕的話, 通常會將framebuffer放在一個看不見的buffer, : 然後在將buffer打到window內, 這部分就跟vram有很大的關係了, : 因為這是一個gpu->vram->vram copy的動作, back buffer到frame buffer的頻寬在 現在來看應該是零頭了 ?? : 因為, GPU跟VRAM溝通是需要做hand-shaking的,而記憶體本身也會有些延遲, : hand-shaking這個動作就是在做: GPU發命令跟記憶體說"我要送資料了" : 接著等一小段時間, 可能是1個tick, 也可能會慢到3~4個tick, : 接著記憶體會回"ok我可以收", 然後又會等1~3個tick去等GPU發資料, : 所以說這些頻寬能力並不是直接拿來乘就好, : 實際頻寬還是需要除掉這些hand-shaking的時間的, : 在這裡我用了比較低的數據去估計, 畢竟我不知道各廠商的記憶體設定:p JEDEC SDRAM家族都有latency的問題. (附註:很久以前上面的某一篇記憶體介紹) 不過,在SDRAM上,雖然有不容易減低的true latency(CL/tRCD/tRP),但是 可以重排SDRAM command要求的順序僅可能的提高利用率. (SDRAM interface) command &ADDR RAx CAx RBx CBx CBy CBz CAy DataQ Ax0Ax1Ax2Ax3Bx0Bx1By0By1Bz0Bz1Ay0Ay1Ay2Ay3 ------------^^^^^^------^^^^^^------------ 上面是一個需要存取(A,x),(A,y),(B,x),(B,y),(B,z) 這五筆資料的情形.但是經過memory controller 重新排序過後就有可能overlap所有的latency. 在一般情形下,不容易達到.所以cpu需要cache 不過在顯示記憶體上, 由於顯示晶片運算對記憶體的需求是locality低, 但是比較規律.所以顯示記憶體的 有效傳輸比例50%是有點低估的...(對主記憶體系統 來講倒是算很高了) : 所以說, 記憶體寬度決定了視訊記憶體是否會成為GPU瓶頸, : 但是或許有人會說, 照這樣算起來, 7900GTX的記憶體根本也達不到需要的頻寬!? : 沒錯, 因為事實上根本沒必要讓記憶體完全跟上GPU, : 透過OpenGL/Direct3D這些API, 可以事先把資料送進VRAM, : 然後之後就不在需要每個frame都送一次資料, 這部分就相當的省時了, : 這使得傳輸的資料可以簡化到大部分都是送硬體命令, : 省下了最佔時間的資料傳輸時間. : 這個時候, game跟game engine設計好壞就可以一分高下了, : 好的引擎跟遊戲設計規劃可以省下許多不必要的資料傳輸, : 對於vram頻寬的需求相對就減少許多, 等等.把什麼東西正確的先放到VRAM中,減少的應該是 "顯示卡bus的頻寬使用"而不是顯示記憶體的頻寬使用. 應該說兩者都會減少,可是高階的local video memory通常比 bus快10倍以上.所以同時減少對bus的效益比較明確. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.114.78.58