※ 引述《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