原文是<stuttering in game graphics:detection and solutions>由nv的技术总监cem cebenoyan在cgdc12上带来。
非常好的介绍了很多显卡底层，从硬件到driver，到windows os的一些知识，受益匪浅。
nvidia在cgdc上一直保持着高水平的presentation，赞！
5个常常会造成图形性能卡顿的原因：
- shader编译
- 显存用光了->使用system memory->paging
- 资源的管理：create/destroy/update
- gpu落后cpu太多帧
- 不好的query：event/occlusion query
cpu/gpu communication:
- driver层面，每个device维护一个cmd buffer，提交的时候是提交给os
- driver一般会在present的时候flush，但是其他地方也可能flush（应该是cmd buffer满了，或者强制flush）
- driver最多会存上3个frame的cmd，也就是gpu最多可能落后4帧
- os的graphics scheduler统一进行调配，压入GPU hardware queue
- gpu进行consume
WindowsDisplayDriverModel:
vista以后才引入了（终于明白为何在xp和win7下，driver行为如此不同的原因了）。
像其他os去封装硬件一样，wddm把显存，graphic task等进行了virtualize。
这里提到了两个模式：
- umd:user mode driver，处理d3d application, 构建和submit cmd buffer
- kmd：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 recompile
- shadow map bound/unbound
- 使用的贴图在fp和非fp格式之间转换--看来fp的texture会使用特殊的sampling指令吧
- 贴图和rendertarget的srgb
- 同样的pixel shader，但是COLORWRITEENABLE的状态不同
- 使用一些枚举或者bool来控制static branch，不同的branch的排列都会造成编译
- d3d9的
- clipplane
- mrt的状态
- 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 stencil
- render target
- frequently used resource : texture
- less used resource:vb,ib,texture
- 重要性一样的话，大的优先，float point的优先
- 超显存的问题并不总是一个严重问题
- 高频率使用的资源都放在显存里了，所以一般不会有严重的paging，所以前面说的是大幅度超显存才是问题
- gpuview里面可以看paging的事件
queued frame
这个一般都是限制gpu不会落后cpu(render thread)超过一帧，但是这里看来似乎并不是最好的策略，如果可以的话落后个多达3帧的话，可以对gpu时间不稳定的情况有更好的容错。
也就是会更平滑。
但是副作用也是比较明显的，比如occlusion query就会晚好多帧。
frame落后有api的：
IDirect3DDevice9Ex::SetMaximumFrameLatency
IDXGIDevice1:: SetMaximumFrameLatency
其他一些会造成性能卡顿
- gpu context switch,比如在graphics pipeline和direct compute pipeline之间切换
- 多个d3d application同时运行的时候，会造成竞争（contention）
- driver的paged/non-paged pool超内存了，xp上面这方面能力相对就差
