[运营期间开发]卡顿处理--GPUView

开发期间的卡顿处理的方法比较多，可以打log等方法。

GPUView
在运营期间就是GPUView就是逆天的给力存在。
GPUView早先是一个微软实习生开发的东东（好逆天的实习生），以单独的方式来发布，后来集成到windows sdk中来，本blog上面这里有一些记录。
而且在后续GPUView依旧保持着发展，功能也越发好用了，连intel的gpa也在底层使用这个机制。

GPUView可以做的事情很多，其原理就是能够抓取一段时间的windows底层的消息（几乎所有你需要的消息），gpu driver，lock，context switch。。。应有尽有。这部分的抓取的applicaiton叫xperf.exe，看的时候是GPUView.exe，当然整个过程我们就简称GPUView了。
而且很棒的一点就是，windows自己会把这些消息缓存一段时间，然后在你抓取的时候，会把之前一段时间的信息拿过来，这对于抓取卡顿太妙了（其余的办法，你发现卡顿，但是这一帧已经过去了，你只能望卡兴叹）。

ps；我老婆认为这个软件太难看，我个人倒是挺喜欢这个hardcore的感觉，和windbg一样，解决问题简洁犀利。

GPUView使用
实际命令行什么的还是有点麻烦，抓取时候可以使用写好的一些GUI工具，在win10上面是这里。
自己随便运行一个程序什么的，然后点击抓取，可以获得一个etl文件。

这里就举一个例子来说明过程：
1，有玩家反映在开封主城附件的豪宅区会有卡顿，于是qq上联系玩家，远程一下，收集到卡顿的etl文件。
2，然后使用GPUView.exe打开这个文件，遍历整个时间段里会发现有一个地方系统处于停滞：有近700ms都没有提交任何GPU命令

3，进一步zoom in，会看见主线程这里在忙，其他都在等，点击其中一个事件（这个是系统以一定间隔来采集执行的信息，点开可以看到进一步的callstack信息）

4，选择主线程，只选择Stack Walk，就可以看到这里的callstack了：

5，这个callstack，在自己有pdb的情况下就可以resolve出来，在gpuview的symbol path那里进行设置，就能看到具体的callstack了：

这时候就知道问题是出在什么地方了。

symbol解析问题处理
GPUView解析不出symbol的问题是经常出现的。
第一步可以做一些诊断：可以参见stackoverflow上面这个帖子
DBGHELP_DBGOUT = 1
DBGHELP_LOG = C:\dbghelp.log
通过这两个环境变量（就是系统环境变量的设置方法）可以把load symbol的过程log出来，实际windbg等一些系统工具都可以用这个办法诊断symbol不能resolve的问题。
通过log可以定位问题，比如我之前的问题就是改了symbol path，但是没有生效，还是到老的地方去找。
可能是gpuview在symbol path改变的生效方面的bug，于是就乱试好了，比如把这几个选项开开关关

然后就好了。
//2018.2.3更新
还发现一个情况就是，起作用的可以稳定搞定的操作是：

• 写好路径，然后apply path，第一次一般不起作用（起作用的时候明显感觉到gpuview软件会卡一下）
• 然后对路径做一个修改，比如把路径结尾的时候加一个”\”或者去掉（output->output\ 或者反过来）
• 然后apply path，正常会有一个小卡顿，就意味着symbol resolve成功了