Re: [問題] Bit數
※ 引述《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
討論串 (同標題文章)
VideoCard 近期熱門文章
PTT數位生活區 即時熱門文章
