flagship的理想与现实

        目前的3D引擎的渲染帧和逻辑帧都是在一个线程上运行的，在网络游戏中大量玩家聚集，繁重的骨骼动画计算和粒子计算极大的拖累了渲染帧数，有两种有效措施：1、控制同屏显示人数，但玩家体验不好 2、帧数低于某值时减少动画Tick频率，但带来的问题是动画不连贯。
        如果考虑使用多线程优化，最容易想到的就是采用平行分解模式，将骨骼动画计算和粒子计算写成两个for循环，然后用OpenMP将其多线程化，但事实上这样并不会提高多少效率，这两者计算仍然要阻滞渲染帧，线程的创建也有一定的消耗。于是我想到了一种极端的解决方案，采用任务分解模式，将渲染和逻辑完全分离到两个线程去，互不影响，当然这样线程同步会是大问题，毕竟线程的数量和BUG的数量是成正比的。
        我们首先来分析下这两个线程分别需要做什么工作，需要那些数据。渲染线程需要获取实体的位置、材质等信息，并交给GPU渲染，逻辑线程需要更新实体的位置、材质、骨骼动画等数据，很显然一个写入一个读取，这为我们实现一个没有线程同步的多线程3D渲染系统提供了可能。
        为了让读取和写入不需要Lock，我们需要为每一份数据设计一个带有冗余缓存的结构，读取线程读取的是上次写入完成的副本，而写入线程则向新的副本写入数据，并在完成后置上最新标记，置标记的操作为原子操作即可。以Vector为例，这个结构大致是这样的：
        当然我们可以用模板来写这个结构，让其适用于int，float，matrix等多种数据类型，余下的工作就简单了，将所有有共享数据的类的成员变量都定义为以上这种数据类型，例如我们可以定义：
        SharedData<Matrix4f>  m_matWorld;
        在渲染线程中调用pDevice->SetWorldMatrix( m_matWorld.Read() );
        在逻辑线程中调用m_matWorld.Write( matNewWorld );

        需要注意的是，这种方案并非绝对健壮，当渲染线程极慢且逻辑线程极快的情况下，有可能写入了超过了DATACENTER_CACHE次，而读取却尚未完成，那么数据就乱套了，当然真要出现了这种情况，游戏早已经是没法玩了，我测试的结果是渲染帧小于1帧，逻辑帧大于10000帧，尚未出现问题。
        FlagshipEngine采用了这一设想，实际Demo测试结果是，计算25个角色的骨骼动画，从静止到开始奔跑，单线程的情况下，帧数下降了20%～30%，而使用多线程的情况下，帧数完全没有变化！