id_Tech5_challenges--siggraph09

http://s09.idav.ucdavis.edu/talks/05-JP_id_Tech_5_Challenges.pdf

 

这个作者--J.M.P. van Waveren，就是那个在quake3发布之前拯救项目的哥们。话说quake3的bot模式，bot总是看起来很傻，行为不像人，大家陷入困境，然后找到了这哥们，成功搞定，被carmack说成拯救大家的家伙。几年后已经成长成全才啦。

 

http://www.cs.rochester.edu/research/quagents/QuakeIII.pdf 

这个文章估计对ai有兴趣的可以一读，或许已经过时了也说不定。

 

进入正文，先看id tech5的能力，这是三平台60帧的游戏：

 

---

 

开始部分是virtual texture的细节

• 使用了128k*128k texel的texture
• texture filter----bilinear with border比较好用，trilinear已经有点费了
• memory trashing-----virtual tex会需要大量的物理内存，这个常常会出现不够的情况，就需要换页了，但是还没换完怎么办，就强制修改mipmap bias，用低精度mipmap先用着，换好页了再切换到高精度，算是一种应急处理方式，很有引擎的dynamic loading也会这么干。也可以使用trilinear filter来做到比较平滑的过度，而不是一个popup，这个pop up可是巨有害的东西，会很容易被玩家捕捉到，尽量避免啊。
• tex load 分析----分析出virtual tex哪个部分是需要load进来的，每个virtual tex使用四叉树组织起来的，分析的结果会产生一个宽度优先的四叉树访问/load 请求。
• transcode----这步比较晕，貌似是读取高度压缩的dct格式的贴图，解压成显卡直接可用的dxt格式。
• virtual texturing pipeline:
• 
• 紫色部分是可以并行的。

 

---

 

Job部分

 

id tech5引擎里这些东西要处理的，也是想并行处理的

• animation
• collision detection
• obstacle avoidance
• transparency sort
• virtual tex
• misc processing
• rendering
• audio

而且面向多平台，多核的pc，3核六线程的xbox360，2硬件线程+7spu的ps3，所以要对这些并行资源进行抽象化。

就生成了job系统，job系统核心理念是：

• 对线程抽象化，变成一种像memory的一种资源
• job scheduler申请到这些资源后，开始接受job，并在这些线程上执行。

早起多线程会像UE3那样，人为切成main thread，render thread然后每个线程里在手动弄出一堆小线程的任务来做。

这就像一种静态数组。

 

job系统更像动态数组std::vector，使用正确的话性能，灵活性，跨平台性都非常好。

 

这个job系统和spu job太像了，可以直接参考学习。

 

一个比较棘手的东西就是sync，sync意味着等待->性能损失。

文中尽可能的要求对job的output晚一帧使用来避免sync。

这个。。。有点太理想化，实际应用中原则就是尽可能避免sync就好，晚一帧是最理想的，实在不行也只能等待了。

 

接下来job还要去支持cuda，larabbee等，很赞。

但是实际工作中我发现job系统的思想是好的，在硬件多核发展以及console平台差异性的趋势下，开发者趋向job系统几乎是必然。

但是也是有很多弱点，像很难debug，写出好的job系统以及良好的使用（稳定而且高效）都仍旧需要开发者付出很多的努力。