※ 引述《VCCS (压控电流源 (啥？))》之铭言： : 好像没有业界强者出来，我自己先google几个贴上来 : 有解释API、DirectX、驱动程式之间的关系，至於正不正确...不要问我 XD : http://www.ns-bbs.com/teach/list.asp?id=63 : API（Application Programming Interface） : 应用程序介面。API是应用程式用来请求和执行本应该由电脑作业系统执行的低阶调整功能 : 。API可以看做是程式和3D图像之间的交互方式，3D设计人员利用API介面编辑程式，对图 : 形处理晶片发出命令，执行多种效果运算，构造出理想中的图形效果。现在流行的显示 : API是OpenGL和DirectX。 稍微补充一下小弟的看法, 其实API用的范围很广, 不限於3D.... 另外, GL与DX是有它的API, 但它们最主要是一整套函式库.... 因为是函式库, 才需要API接口给程设师, 所以说流行的API是GL和DX怪怪的.... 应该说目前主流的3D函式库是DX和GL, 其中DX最显着的不同是多了一层runtime.... (当然你要说DX是MS独大主导之类的也OK啦, 不过小弟目前重点不是放在这里) 许多杂事MS都透过这层runtime处理完才会给Gfx驱动程式收到.... 这也是为什麽有时候新游戏会跟你说要安装DirectX x.x版.... 至於DX的架构延革请上MS网站吧, 小弟其实跟DX一点都不熟XD : DirectX : 微软作业系统平台下的游戏程式开发介面，即所谓的Game API for windows。一般来说Dir : ectX是由一系列硬件驱动程式（如显示卡、音效卡等驱动程式）组成的，其主要的部分包 : 括Direct Draw、Direct Input、Direct Play和Direct Sound，分别针对显示、输入系统、 : 网路通讯和音效等各方面。DirectX最大的优点是提供了高效率的驱动程式而使游戏设计 : 的程式介面得以统一，让程式可以做到与硬体无关（Hardware Independency）。 : 这里有更详细的directx与驱动程式介绍 : http://zh.wikipedia.org/w/index.php?title= : %E9%A9%85%E5%8B%95%E7%A8%8B%E5%BC%8F&variant=zh-tw : http://zh.wikipedia.org/w/index.php?title=DirectX&variant=zh-tw : 上面两个太复杂，这边还有个简单易懂的解释 : http://www.mobile01.com/topicdetail.php?f=298&t=399440&last=3587903 : 业界急需一个共通的中介标准，於是微软制定了第一代DirectX，这是一种「应用程式介面 : 」（API，Application Programming Interface）夹在软硬体之间，虽然多了第三者会减 : 损效能，但换来的方便性是绝对值得的 : 虽然显示卡一定得支援DirectX，但实际GPU晶片线路要怎麽设计则是各家厂商的创意，就 : 像x86 CPU不能直接执行x86指令，得透过内部的解码器转换，GPU也不能直接执行DirectX : 的指令，中间还得透过驱动程式，这也是为什麽显示卡的驱动程式超级重要，因为它得解 : 译DirectX的指令，转换成GPU看得懂的机器语言（Machine Code），驱动程式会直接影响 : 显示卡的效能和功能。 顺便引述您的前一篇回文一起回好了.... : 1.GPU不能单独存在，只差显卡你电脑能开机吗？ (废话) : 2.GPU需要听从CPU指挥 (这好像也是废话 囧) : CPU不仅要从事游戏的逻辑运算、物理运算，还要从事API转换(如directx转成GPU指令) : 以及显卡驱动在kernel、user mode之间转换等等.... : 简化的讲，显示卡不吃你游戏的指令，而是吃CPU翻译过後的指令 : 怎麽翻译？那就靠驱动程式了 : 因此才有板上ATi迷激赏的，Catalyst每换一版驱动效能大增 : 或是NV迷不屑的，你看果然ATi以前驱动多烂阿.... CPU要从事的工作有游戏本身的处理: AI, 介面, 操作, 或没GPU加速的物理; 太多了. CPU也有一部份是做DX API的处理: DX runtime, 还有API<->driver资料的传递.... CPU再来要做的就是driver相关的: API传来的资料, driver对SW/HW的多工管理.... 将runtime传进来的MS指令转换成真实GPU指令, 协助resource的管理.... 当然还有更多因为GPU的特性/bug/其他理由会由CPU协助GPU来工作等.... 最後(可能还有其他啦, 一时想不到): 就是OS本身的需要.... GPU要做的工作动态的像是shader执行(这里已经是CPU翻好的GPU可以运行的指令了) 传统VS的TnL, PS的texturing/blending的计算, 甚至GS/GPGPU等指令的执行.... 固定性质的工作像是rasterization(三角形顶点转像素平面), Z(深度)等test.... 还有像texel的sample/fetch, filter; 族繁不及备载(其实是一时想不出来了) 以GPU来说, VS/GS/PS这些process除了被cull/clip或者test fail丢掉的以外.... 基本上AP送了多少Vertex/Pixel出来, GPU就要去做多少的事情.... 当然GPU HW与3D pipeline的设计会尝试减少不必要的工作就是了.... 反过来以CPU来说, 现今DX/driver的设计会尝试让能给GPU做的就别烦CPU.... (毕竟现在CPU与GPU processor unit的数量差异极大.... 而System Mem<->Video Memory资料的传递也是非常消耗时间的) 还有, CPU处理过一次就能解决的, 就不要浪费时间做第二次, 有几点小弟知道的.... 1.比如DX10的例子, StreamOut让VS/GS的结果直接保留在VideoMemory里.... 让下一轮的draw可以直接当作新的Vertex data来用, 减少由CPU处理的必要.... 又例如instance, 让你事先指定rendering的素材匹配, 减少CPU切换state的动作.... 2.以AP下的shader code来说, runtime翻成MS指令後没必要就不用翻译第二次.... (这点小弟比较没把握, 因为小弟比较在搞的GL没有runtime, 总之请搭配下一行) 因此, driver发现是同样的MS指令, 就不用重做翻译成GPU指令的动作.... 3.Driver的优化, 这就看各家driver team的本事了, 当然多少与HW能力有关就是了.... 这一部份甚至牵涉到您说过的user mode与kernel mode driver与OS的沟通频率.... 不过换驱动"部份"游戏效能大增的情形, 算是另一种优化, 这个後面再谈.... 4.许多游戏的loading time, 常常就是在做shader翻译, texture load等工作.... 这边做过了不必要就不用再作; 有一个和VRam相关的问题是, 如果VRam太小.... OS可能就要管理PageIn/Out的swap动作, 这无庸至疑的可能造成效能低下.... 而CPU从事游戏本身的工作小弟的认知是有很多事是可以偷懒或给限定时间的.... 比如AI, 我可以固定分time slice给每一单位AI思考时间, 过了就跳过它.... 或者依CPU的闲置情形/运算能力有不同种类复杂度的规划方式.... 这边因为偏离主题, 小弟也不是那麽清楚, 所以就别野人献曝了:) : 大大你用"匹配"这个字眼，我认为比不上用"喂饱"传神 : 赛车引擎用"匹配"的轮胎，因为引擎没有管到轮胎 : 但藤原拓海与86是单纯"匹配"，还是他有本事"喂饱"了86 XD : 还有推文讲的GTA4，因为太吃CPU了，是爱妻"匹配"不了GTX 280 : 还是爱妻也喂不饱GTX 280，所以GTX 280还有点饿？ : 哪个传神呢？ (迷之声：糟糕起来了)　 至於匹配或者喂饱, 小弟以为sdcheck板友已经很简单而传神的表达其含义了.... 在这边就简单提一下小弟所知道的早期的GPU到现在的GPU+CPU的工作情形.... 早期的Gfx内, VS与PS unit的数量是固定的, 而通常PS的数量比VS的还大得多.... 因为三个三角形的顶点(vertex), 可以生出三百的像素(pixel)出来.... 然而, 假设今天有个游戏VS的负载比较重, 导致PS许多unit闲在那等VS吐资料.... (当然VS不会直接吐资料给PS, 中间至少经过rasterizer, 意思到就好了) 这样的case就算我PS unit很多, 游戏的performance也很难好, 而且很难救.... (你当然可以设计有更多VS unit的HW, 不过游戏这麽多, 能每款出一张卡吗^^||) 於是Unified Shader(统一着色器或泫染器)架构的优势就突显出来了.... 如果Gfx发现VS loading比较重, 就把较多unit给VS, 反之亦然.... 而更优秀的HW/SW还能依游戏情形自动调整成合适的比例, 不然就用driver硬调.... 上面废话了这麽多跟CPU的关联是??今天整个OS上执行游戏需要driver辅助.... 将需要执行的工作交给CPU与GPU去做, 但是却不是什麽游戏loading都一样重.... 就像上一段GPU的例子, 也许有的CPU重一点, 有的GPU重一点, 很难统一认定.... 不然就像板友说的, 你都买最贵的CPU+GPU, 就不用想匹配或喂饱的问题了.... 也因为是case by case, 所以每每A家N家新的driver release出来以後.... 就能对什麽game或benchmark(可能哪一关)有多少%的效能成长; 所以说benchmark~~ 这就是为什麽我们常说benchmark未必能忠实反应游戏上的表现.... 1.因为那几套benchmark早就被优化, 甚至是偷鸡作弊到烂了(在不易查觉的程度吧) 2.随着新游戏新引擎新技术的引进, 既有的benchmark未必能反应所需的特效.... (不过小弟还是认同benchmark对Gfx基本的评测能力, 尤其新组电脑的时候~~ 或者你发现为什麽相似配备相同游戏你跑起来FPS远比人家逊很多....) 3.因为每一套游戏都可能有各自的SW bound或HW bound, 这需要经过一些tool的分析~~ 甚至是Gfx HW自己design的一些counter来让driver team知道现在效能瓶颈在哪.... (更进一步的, 下一代, 或者下一个改良版HW, HW的design可以在哪做强化) 其中, 监於GPU平行处理的能力, 所以会有什麽物理特效给GPU做啦.... 甚至是Video的encode/decode等工作拿来给GPU做的(硬体编解码??) 不过, 高等级的游戏常常在3D运算/显示的部份就把GPU搾乾了.... 是否有把物理特效拿进来的余裕就是另外一个问题了.... (至於要不要CF/SLI, 不管要不要独立一个算物理, 就是荷包与爽度的问题了) 最後, 游戏写的好不好, 能不能有效的运用DX/GL与GPU去工作.... 同时减少CPU运算不及造成的冲击(或者对多核CPU做最佳化)就是游戏设计者的工作.... (包含非游戏的AP像PhotoShop/Flash要不要利用GPU平行化/最佳化以增进效能等) 所以小弟原先才会推要看游戏/OS/HW/Driver整合起来看.... 才有这个不管想叫匹配还是喂不喂得饱的问题.... 当然我想扣掉板友说过的极端的组合, 比如E1xxx却装了GTX295这样.... 搞不好你CPU本身做什麽都慢了, 说不定光防毒软体就吃光你CPU loading了勒.... 补充一个, 早期的IGP(内显)有的可能为了省gate count, 而没有HW TnL.... 那它的VS会用CPU算, 这个CPU对GPU就有相当程度的影响.... 或者基於某些理由(HW不支援某些feature等)全程用CPU算.... 虽然~~这一类的GPU效能可能也高不到哪里去就是了....@_@" : 就这样，我是喂饱派的 XD 就这样, 小弟我什麽都不会, 只是今天工作还有固定要运动的行程都不顺利.... 所以梦到了上来骗骗看P币这样, 有谬误或不足得还请各位先进指教....<(_ _)> --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.132.174.98