po在这里好像怪怪的,如果有人认为不适合我再砍吧.... 小弟不敢称什麽专家,写些算是很粗浅的概念,大致上是directX的, 不过其实3d这东西大致上是这样. 不太会画图,所以用连结的,下面是msdn direct3d9的pipeline, 我们先不要管shader model3.0之後太复杂东西,先来基本的 http://msdn.microsoft.com/en-us/library/bb219679(VS.85).aspx 这是一个很基本的d3d9 pipeline,相信很多人都很熟了, 毕竟这架构很久了,还是简单的说一下, vertex data:可以想像成一堆vertex,他可能代表一个物体,甚至是数个物体 都没关系,整体而言就是一个很大的buffer储存我们需要的vertex primitive data:假设我们上面的vertex data是一堆物体,那我们要如何取得 一个物体的vertex?答案很简单,我们利用index的方法,也就是把上面的vertex编号, 而每个物体只要把他对应的indices给纪录下来就好了,因为index只需要一个16或是 32bits的数,然而我们每个vertex光他的座标就是三个32bits的浮点数了. 更何况还有类似normal等其他东西,那为什麽不乾脆每个物体都用一个vertex buffer 就好?这其实也是蛮多问题的,最基本的就是一般而言,我们不断的换vertex buffer 来render对硬体是不好的,所以我们改用一个大buffer而来swap index会是比较有效率 的做法,另外,有些架构上并没有办法分的那麽开,假设我们有一个很大的城市我们 把他放进一个buffer,那我们可能需要运算的并没有那麽多,我们可以用index的方式 只取一小段进入pipeline来处理. tessellation:这其实是类似patch比较会用到,有些只用参数定义的面, 我们必须把他解析为点,可以先无视,印象中蛮少人用patch的,我是指游戏... vertex processing:这就是一般vertex shader做的工作,我们在这边做 transformation matrix的乘法,将座标系转换到screen座标系,或是决定每个 vertex的颜色,一般基本上做的就是这些 geometry processing:因为还没有dx10,这边一般做的,是所谓back-face culling, polygon有两面,如果是反面,没有正对镜头的,那就没有必要画,所以有些游戏例如你 偷看裙子里面你会发现衣服内侧是透明,那是因为他被判定是back-face,所以没有画, 基本上这都可以设定啦...但是一般为了效率看不到就不会画. 另外还有就是clipping,我们前面已经把vertex data转到萤幕座标系了, 这时候如果超出萤幕外的顶点实际上是不需要的,这时候就会裁掉,因为我们等一下要 进入load重的pixel范围内,这时候能砍的就砍 textured surface,texture sampler:我们把物体表面对应的texture座标找出来 并且取他的颜色,送进去pixel shader做着色的参考 pixel processing:基本上就是把pixel着色,也是pixel shader的主要工作, 我们根据前面vertex的颜色做内插找出夹在中间pixel的颜色,和贴图的颜色做结合 pixel rendering:根据z值,alpha,fog来决定最後的颜色,至於stencil这和 阴影一些特殊用法比较有关,这里我们只顾基本盘,不要理他. 上面讲那麽多,其实我们可以看到: 1.d3d pipeline里面和CPU根本没关系 2.解析度的大小,其实比较有关联的pixel shader的部分,除非例如4:3变成16:9, 那我们可能会改变可视范围让东西加进来,不然基本上都是和pixel才有关联, 所以cpu基本上和解析度的相关性也是极小 那CPU真的没有用吗?其实这只是因为directx本来就是拿来做graphic部分, 所以单从directx来看和cpu的关联性并不高.但是其实cpu还是和graphic pipeline 有息息相关的.所以上面的还是要介绍一下. 我们从pipeline来看,一旦我们要进入pipeline的时候,我们的input要是什麽东西? vertex,index的资料,再来还有这边没有看到的,就是transformation matrix, 这东西本来应该是在vertex shader,他是作为一个input,我们需要他的world matrix,view matrix,project matrix,world matrix就是这个物体在3d世界的座标 转换矩阵,基本上我们画3d都会做一个标准座标系,而我们最後的目的就是要把他 转到萤幕的座标系,这样我们才可以说,萤幕座标(x,y)的点,是对应到这个3d的哪些点, 然後用这些点来决定颜色,我们一般都称为world transformation matrix,因为 通常我们可能有一个起始座标,而物体如果移动,这中间的转换,我们藉由这个矩阵 来达成,所以我们前面pipeline提的vertex data里面有包含座标其实是起始座标, 然而藉由不断改变world矩阵,我们可以让物体移动到这个世界的任何地方. 另外view matrix则是由camera决定的,如果camera移动,就会改变他, 而最後的project,你可以想像成这是一个camera的参数,他的用途是camera视角转到 萤幕的对应,如果你camera的参数没有改变,这基本上是不变的.藉由vertex shader, 他就是把vertex藉由index选出,然後照顺序每次处理一个vertex,而这个所谓的处理, 就是把里面的矩阵乘一乘,这样的话,我们不会常常去动到vertex buffer,index buffer内部,只要选择挂上不同的buffer,指定不同的matrix给shader,就能做出运算. 综合上面所讲的,我们通常需要设定一个vertex shader的,有三个matrix, 但是这三个matrix是怎麽算出来的?这是靠cpu,其中,view和camera移动有关, 而且通常都是只有一个camera(除非是动态反射),project通常不变,那剩下的就是 world matrix了,所以每个会移动的物体都会造成cpu的使用. 我们可以说: object相关的是由cpu去做, vertex相关的是vertex shader, pixel相关的pixel shader, 他们的单位划分基本上就是这样 以物体的行为来看,如果我们需要知道一个物体怎麽移动,那需要什麽? 如果是我们操作的,那需要input,而如果不是我们操作的,那就需要AI, 再来两者都需要就是碰撞,或是一些物理上的性质,再来如果有animation, 那我们需要决定animation. 基本上来说,AI,物理,这都是比较操的部分,AI除了决策外,还有所谓的path finding, 也就是找路,这算是比较特殊却又不可获缺的东西,甚至他还包含了很多碰撞在里面, 物理更不用说了,最基本的碰撞就让人伤透脑筋,物理特性就不赘述,你简单力学 有碰过的现在很多游戏都有,另外最近也开始有作品做出动态的破碎或是损害效果, 有些看起来是能藉助shader model4.0,不过目前市面上有一口气要求一定要4.0以上 的卡的游戏.....我不太清楚,应该没有吧? 大部分要做还是要看cpu.另外我还看到有人开始做dynamic animation, 利用计算平衡的方式来算animation,这基本上也是很强的物理运算了. 除了这些外,还有culling,我们前面已经有提过,pipeline中有culling的动作, 然而我们仔细看的话,会发现culling是发生在vertex shader和pixel shader之间, 所以一般游戏还会做额外的culling,目的是为了上vertex shader能处理的vertex 更少.当然现在有很多演算法,有些甚至先用比较简化的方式render一遍来做这种 culling,但是基本上这东西以倚靠cpu运算还是无可避免的,还有现在LOD也已经 很多游戏用了,这也是消耗cpu运算的部分.以上是我粗浅想到一般cpu比较在做的东西. 如果拿这个运算和gpu比较到底比例是多少,这是个无解的问题,程式的东西, 你要写多操就能有多操,或许就一个画面的量来看,gpu的运算是惊人的,每个pixel 都要算,倒推回去每个pixel所经过的物体都要算,而且现在render都很复杂,multi-pass 的大量使用使得一个画面都不只是一个画面的运算量,还有per-pixel lighting的比重 也都是相当的负荷,更不提一些多算的culling掉的,但是cpu负责的可没个范围, 先不提那乱七八糟的物理可能有多复杂,我也写过cpu的运算要到per-vertex, 甚至一般我们shader比较避免的增减vertex(除非你用4.0),这可能还会额外增加大片 的memory搬移运算,另外超过画面外的东西,要多少就有多少,无接缝地图背面可能是 大量的cut scene,lod,外加cpu还要负责一般gpu比较少的branch运算,这对 performance hits不言可喻,平行化处理也没那麽强,举凡graphic,physic,AI,music, sound,I/O,network,disk access这些的帐都算在他头上,现在还有要解压缩贴图还是 资料的,真是乱七八糟,包山包海的,要真的搞起来,有时候cpu这边的负担更是无法想像 之重,且更难去optimize他.这边的演算法的变化性也相当之大. 上面所说的都是一个fps要产生一定要经过的,所以cpu和gpu之间的合作本来就是 相辅相乘.而有人会说喂这个动作其实也无可厚非,因为在进入gpu作业之前的前置 全部都是cpu算出来的,我们把结果算好,参数设完,然後才启动shader,所以我们会把 cpu的结果拿给gpu去当输入,说是喂其实还蛮贴切的.很多外国的文件也是用feed这个 单字,有点像是叫cpu把要拍的东西都摆好後,gpu过来拍一张照片就走人了,至於摆这些 东西要花多久时间,空间其实很大. 提一个之前读过ati对於optimize的建议,算是一个蛮基本的概念. 这两个东西都有其独立的运算,最好的型态,就是当我们将cpu的结果得出後送给gpu, gpu开始运算的时候,cpu就开始下一个frame的运算,而得到结果後,刚好gpu也把 上一个frame给算完给显示了,这时候接着下一个开始做,这样下来cpu,gpu都没有闲着. 一直做下去,如果cpu delay或是gpu delay,会影响另外一个的运算时间. 即使这篇文章是很久以前的东西,现在还有的pipeline feedback,不过其实可以 大致上看到这个精神所在,如果cpu处理时间过长,那麽gpu需要等结果才能开始 绘制画面,如果gpu很慢,那cpu算出来的结果必须hold住,等到gpu结束运算我们 才能把结果给feed过去,在xbox360中,directX SDK里甚至还提到开始delay一个frame 的做法,也就是其实我们每次显示都是晚一个frame,让cpu做足一个frame,下一个frame time才丢给gpu算,而gpu也做足一个frame,虽然显示晚一个frame,但是这样的感受对 玩家而言其实相当难以查觉且不影响游戏性的.所以gpu和cpu之间的平衡一直是 game programer要注意的. 重点来了,到底要怎麽知道我的软体目前是cpu bound还是gpu bound? 我引一个nvidia在gpu gems里面提到的有关optimize的东西: http://http.developer.nvidia.com/GPUGems/gpugems_ch28.html 在图28-2里面这是一个制作者拿来测试现在performance到底是cpu bound还是 gpu bound,老实说放在这里可能有点不伦不类,但是我想还是可以看一下软体制作者 是怎麽做的,我们写程式的也是要知道现在到底瓶颈在哪里,才能最佳化.现在玩家 可能角度不一样的是,我们可能要藉由硬体提升来解决performance issue, 老实说我认为在这里提蛮没意思的,毕竟你只要换一颗cpu看fps有没有增加不就知道 了?^^ 不过还是想让大家看看开发者的做法,我们得从pipeline倒过来,我们先想办法 移除gpu上的变因,接下来才能得知是否是cpu bound.因为我们cpu负责的是喂给gpu 之前的资料处理,也让大家知道,对玩家而言,其实说实在还真的除了换一个试试看, 要直接从tool的角度来下手其实不太可能. 首先我们要先问,到底什麽样的标准才算是合格?就软体工作者当然有他开发的平台 标准,就玩家来看,应该还是开同步吧?大概60fps就够了,讲是这样讲,我下面也没 什麽数据啦@_@ 1.首先他先确定是否为frame buffer频宽,从pipeline最後的raster operation着手, 也就是前面提到的pixel rendering,我们藉由改变32bits到16bits这种depth buffer size的方法,不过这一般的游戏通常是不会有这个选项给你选的,虽然有些tool可以 从外部去更改,但是我们首先也要知道他原来用的是什麽size^_^ 或是这样的override有没有效,才有办法去测. 2.texture size/filter,这可能一般游戏比较容易可以调整 3.解析度,这也是可以调的,可以看看下面的解说,里面有提到这最主要测 pixel shader,虽然他和第一项都和fillrate有关,但是因为我们在pipeline中 这是属於两个不同的stage,所以分开测. 4.vertex processing:基本上是测vertex buffer,又来了,这我们根本不可能去测, 因为我们不太可能去改vertex shader的程式,玩家根本束手无策 5.vertex index transfer:这其实解释起来有点麻烦,一般我们 vertex buffer,index buffer,是有可能放在系统记忆体或是显示卡记忆体上面, 我们可以指定一定要放在系统,例如dynamic vertex,我们需要cpu运算来改动 vertex buffer,那放在系统会比放在显示卡好,如果我们不会去动到vertex, 当然放在显示卡比较好,然而显示卡记忆体是会爆的,所以我们只能用参数建议, 而并不能直接去干涉,但是问题就来了,如果放在系统上面,那一旦要画的时候, 势必要经过agp或是pci-e传到显示卡,那这之间的频宽问题就可能会影响到了, 也就是这个地方想要测的东西.还是老话,这根本不是玩家可以测的,别闹了,连写程式 的都不一定会确定directX把东西放在哪里了,还得花一番功夫测,我们玩家连参数下 什麽都不晓得,要怎麽知道?? 如果gpu的要素都移除了,接下来才是cpu的问题,也就是在开发阶段,我们的确可以 用喂不饱这种形容词来说.我认为,玩家要知道是不是cpu还是gpu的问题, 要得到准确性的结果是不太可能的事,我们顶多就只能就我们能看的选项调一调, 基本上那些解析度,贴图相关的,如果调一调没差多少,有可能是cpu问题,而在无法 完全移除gpu变因之前,是否为cpu变因其实无法如此斩钉截铁.所以即使不够力, 也不能排除cpu问题...@___@而且这还只是单针对开发中的graphic part,如果以 一个完整游戏去测,他还有很多graphic以外的变因都随时在困扰着cpu. 结论:打了那麽多字,听起来像废话一样 所以你要知道你现在cpu够不够,应该要先问你显示卡够不够力,才会有下个问题吧? 不然两个都是变因,且A会影响到B,那至少也得先移除B的原因.不然就直接赌一把 换了就对了啦...反正买好东西以後也用的到-_-a 很多游戏着重的都不一样,也无法一概而论,偏高物理,AI,或是大的open map的, 通常会比较需要cpu,现在一般而言其实大部分的软体还是gpu bound吧?常常一调个 解析度就fps掉的乱七八糟的,既然连gpu bound都没厘清,那我们要怎麽去确定他 又是个cpu bound的东西呢??有时候,玩家暴力地使用硬体更换得到实际的数据 其实反而还比较容易反应出结果. 游戏有建议配备,可以先参考一下那个,每个游戏一定有订标准,照道理说, 这种东西的确也只有开发者能抓的准,我认为cpu其实比较好的一点,在於其实现在 大部分都还是针对双核心,一些游戏thread没用那麽多个,毕竟thread这东西不是说 开越多就越猛,有些架构设计下开那麽多反而糟糕,还有thread的同步问题或是使用 时机,种种都导致核心再多也无用武之地,而这也只有开发者才比较晓得,时脉其实 大致上不太可能要求到3G,如果没和intel挂勾的话..... 话虽是这样讲,现在越来越多游戏的趋势是在游乐器上开发,pc版本那个建议配备 说实在还是乱不准一把的,买东西还是看预算看c/p比较重要,如果有那个预算也就没 这种问题了,反正都买高档的还不行也只能死给他看了,要是没那麽有钱的话还 不如挑合适价位的买,不然买台游乐器算了,至少最佳化都比较好,还不用看这篇长文 废话.... --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 123.192.157.54 没办法啊...如果要知道cpu,gpu做什麽,不讲这还不行勒... 写3d游戏最麻烦的就是,明明只想搞软体,为什麽都要搞硬体...:~~~~ 这可能要请问一下了,因为我也没有trace过,不过根据sdk里面,xbox有三核,每个核有 两个hardware的thread,除非他一开始就是为了跨平台,不然有六个硬体thread只开到 2~3个确实有点少,不过当然thread也不是说有那麽多就尽量开吧^^ 在文件里面有建议的设计model里面针对360也用了6个thread,不过另外三个其实比较偏 非必要性的,只是我觉得把这种model如果原封不动拿到pc上,那个效率可能会是... cell其实蛮扯的....看的懂日文可以看一下这两篇... http://game.watch.impress.co.jp/docs/20050519/ps3_r.htm http://game.watch.impress.co.jp/docs/20060331/ps3_2.htm 其实我想这边能人那麽多应该大概都知道了,可能只是班门弄斧... 第一篇讲的是cell的架构,基本上就是一个管理搭配搭配数个simd的用法, 第二篇是当初cell很低迷的时候,他们提出来要怎麽用 cell才能发挥他真正的价值,答案就是:把他当gpu用,看完第二篇只能点点点..... 其实我第一次看到cuda还想说这东西还和cell架构还真有点像 这真的是蛮扯的做法,实在不晓得当初设计的时候在想什麽.... 的确都忘了开发成本这件事了,而且跨平台还可以多捞一笔..... 其实我自己还蛮喜欢sdk里面建议的那个架构,如果有多核的平台的话应该是 很不错的idea. ※ 编辑: tea999 来自: 123.192.157.54 (01/21 04:03)