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系统以及良好的使用(稳定而且高效)都仍旧需要开发者付出很多的努力。