首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 其他教程 > 其他相关 >

[cgdc12][nvidia]显卡底层常识

2012-08-22 
[cgdc12][nvidia]显卡底层知识原文是stuttering in game graphics:detection and solutions由nv的技术总

[cgdc12][nvidia]显卡底层知识

[cgdc12][nvidia]显卡底层常识

原文是<stuttering in game graphics:detection and solutions>由nv的技术总监cem cebenoyan在cgdc12上带来。

非常好的介绍了很多显卡底层,从硬件到driver,到windows os的一些知识,受益匪浅。

nvidia在cgdc上一直保持着高水平的presentation,赞!


5个常常会造成图形性能卡顿的原因:

shader编译显存用光了->使用system memory->paging资源的管理:create/destroy/updategpu落后cpu太多帧不好的query:event/occlusion querycpu/gpu communication:[cgdc12][nvidia]显卡底层常识

driver层面,每个device维护一个cmd buffer,提交的时候是提交给osdriver一般会在present的时候flush,但是其他地方也可能flush(应该是cmd buffer满了,或者强制flush)driver最多会存上3个frame的cmd,也就是gpu最多可能落后4帧os的graphics scheduler统一进行调配,压入GPU hardware queuegpu进行consumeWindowsDisplayDriverModel:vista以后才引入了(终于明白为何在xp和win7下,driver行为如此不同的原因了)。像其他os去封装硬件一样,wddm把显存,graphic task等进行了virtualize。这里提到了两个模式:umd:user mode driver,处理d3d application, 构建和submit cmd bufferkmd:kernel mode driver, 在os的kernel mode运行,管理硬件资源操作系统则在两种模式之间管理command queue
工具提到了3个,fraps,nsight,gpuview。这个GPUView以前还真是没听说过,是微软开发的,开发者的主页:http://graphics.stanford.edu/~mdfisher/GPUView.html,这哥们截止到现在5篇siggraph。GPUView可以提供大量的详尽的信息。一些细节:如果lock的资源在被gpu使用,那么这个lock函数(在某些flag)就会卡住显存超出比较多的时候,会出现严重的paging
回到典型的5个会造成卡顿的原因:
shader编译:我们写的hlsl,编译成asm后,在gpu运行的时候会进一步编译gpu需要使用的机器语言,这个语言是我们开发时候offline生成不了的,因为不同的gpu有不同的指令集,这个过程是driver在运行时刻完成。一般来讲,是在CreateShader时候生成这个机器语言,但是实际中有一些例外:对于一些很复杂的shader会先生成一个能用的,但是优化的不好,然后后面时间富裕了在生成一个高度优化的有些state的转换会造成shader机器指令的编译,比如有的gpu会把alpha test变成shader里面的clip语句,进而就不用提供硬件的alpha test,那么这种render state的转换也会造成shader编译,一些会造成shader recompileshadow map bound/unbound使用的贴图在fp和非fp格式之间转换--看来fp的texture会使用特殊的sampling指令吧贴图和rendertarget的srgb同样的pixel shader,但是COLORWRITEENABLE的状态不同使用一些枚举或者bool来控制static branch,不同的branch的排列都会造成编译d3d9的clipplanemrt的状态fog一些比较好的建议:loading的时候把shader create出来,并且把各个mesh至少都画一遍,这样保证runtime的时候就不用recompile了streaming的话,就render一个看不见的物体好了,反正保证画一遍如果都做不到的话,保证在createshader和使用shader之间有0.5s到1s的时间缓冲把一些严重的state放在一起画,资源管理在vista以及后面的os上,资源创建的时候,内存不总是在create的时候分配,很多情况是在第一次被使用的时候大型资源的创建很耗费频繁的create/destroy会产生碎片,pool会改善这一点一些会造成同步的点,本来gpu和cpu是异步运行,一旦同步就会导致系统停顿,直到同步lock系列(在一定的flag下)在release了一个大资源之后,创建一个大资源(oops)一些建议lock和map的时候使用discard flag,这个会新创建一个资源,而不是等待gpu使用上一个经常更新的资源使用dynamic&NOOVERWRITE flag,这样driver会倾向于把资源放到systemmem,一些比较小的vb,ib,tex放到systemmem也ok啦尽量pool,而不是runtime的去create&destroy自己管理的pool,在释放和重用资源的时候,记住要query一下gpu使用它的情况,这个不像单独的一个资源有driver帮着管理,自己的pool就要多费些力气如果一定要runtime的create&destroy,保证先destroy,然后create,一小会的超内存也会让driver管理内存的时候傻眼显存的allocate策略是先到先得按照重要性的顺序来alloc显存depth stencilrender targetfrequently used resource : textureless used resource:vb,ib,texture重要性一样的话,大的优先,float point的优先超显存的问题并不总是一个严重问题高频率使用的资源都放在显存里了,所以一般不会有严重的paging,所以前面说的是大幅度超显存才是问题gpuview里面可以看paging的事件
queued frame这个一般都是限制gpu不会落后cpu(render thread)超过一帧,但是这里看来似乎并不是最好的策略,如果可以的话落后个多达3帧的话,可以对gpu时间不稳定的情况有更好的容错。也就是会更平滑。但是副作用也是比较明显的,比如occlusion query就会晚好多帧。
frame落后有api的:IDirect3DDevice9Ex::SetMaximumFrameLatencyIDXGIDevice1:: SetMaximumFrameLatency
其他一些会造成性能卡顿gpu context switch,比如在graphics pipeline和direct compute pipeline之间切换多个d3d application同时运行的时候,会造成竞争(contention)driver的paged/non-paged pool超内存了,xp上面这方面能力相对就差




热点排行