flagship的理想與現(xiàn)實

        目前的3D引擎的渲染幀和邏輯幀都是在一個線程上運行的，在網(wǎng)絡游戲中大量玩家聚集，繁重的骨骼動畫計算和粒子計算極大的拖累了渲染幀數(shù)，有兩種有效措施：1、控制同屏顯示人數(shù)，但玩家體驗不好 2、幀數(shù)低于某值時減少動畫Tick頻率，但帶來的問題是動畫不連貫。
        如果考慮使用多線程優(yōu)化，最容易想到的就是采用平行分解模式，將骨骼動畫計算和粒子計算寫成兩個for循環(huán)，然后用OpenMP將其多線程化，但事實上這樣并不會提高多少效率，這兩者計算仍然要阻滯渲染幀，線程的創(chuàng)建也有一定的消耗。于是我想到了一種極端的解決方案，采用任務分解模式，將渲染和邏輯完全分離到兩個線程去，互不影響，當然這樣線程同步會是大問題，畢竟線程的數(shù)量和BUG的數(shù)量是成正比的。
        我們首先來分析下這兩個線程分別需要做什么工作，需要那些數(shù)據(jù)。渲染線程需要獲取實體的位置、材質(zhì)等信息，并交給GPU渲染，邏輯線程需要更新實體的位置、材質(zhì)、骨骼動畫等數(shù)據(jù)，很顯然一個寫入一個讀取，這為我們實現(xiàn)一個沒有線程同步的多線程3D渲染系統(tǒng)提供了可能。
        為了讓讀取和寫入不需要Lock，我們需要為每一份數(shù)據(jù)設計一個帶有冗余緩存的結構，讀取線程讀取的是上次寫入完成的副本，而寫入線程則向新的副本寫入數(shù)據(jù)，并在完成后置上最新標記，置標記的操作為原子操作即可。以Vector為例，這個結構大致是這樣的：
        當然我們可以用模板來寫這個結構，讓其適用于int，float，matrix等多種數(shù)據(jù)類型，余下的工作就簡單了，將所有有共享數(shù)據(jù)的類的成員變量都定義為以上這種數(shù)據(jù)類型，例如我們可以定義：
        SharedData<Matrix4f>  m_matWorld;
        在渲染線程中調(diào)用pDevice->SetWorldMatrix( m_matWorld.Read() );
        在邏輯線程中調(diào)用m_matWorld.Write( matNewWorld );

        需要注意的是，這種方案并非絕對健壯，當渲染線程極慢且邏輯線程極快的情況下，有可能寫入了超過了DATACENTER_CACHE次，而讀取卻尚未完成，那么數(shù)據(jù)就亂套了，當然真要出現(xiàn)了這種情況，游戲早已經(jīng)是沒法玩了，我測試的結果是渲染幀小于1幀，邏輯幀大于10000幀，尚未出現(xiàn)問題。
        FlagshipEngine采用了這一設想，實際Demo測試結果是，計算25個角色的骨骼動畫，從靜止到開始奔跑，單線程的情況下，幀數(shù)下降了20%～30%，而使用多線程的情況下，幀數(shù)完全沒有變化！