目前的3D引擎的渲染幀和邏輯幀都是在一個線程上運行的,在網絡游戲中大量玩家聚集,繁重的骨骼動畫計算和粒子計算極大的拖累了渲染幀數,有兩種有效措施:1、控制同屏顯示人數,但玩家體驗不好 2、幀數低于某值時減少動畫Tick頻率,但帶來的問題是動畫不連貫。
如果考慮使用多線程優化,最容易想到的就是采用平行分解模式,將骨骼動畫計算和粒子計算寫成兩個for循環,然后用OpenMP將其多線程化,但事實上這樣并不會提高多少效率,這兩者計算仍然要阻滯渲染幀,線程的創建也有一定的消耗。于是我想到了一種極端的解決方案,采用任務分解模式,將渲染和邏輯完全分離到兩個線程去,互不影響,當然這樣線程同步會是大問題,畢竟線程的數量和BUG的數量是成正比的。
我們首先來分析下這兩個線程分別需要做什么工作,需要那些數據。渲染線程需要獲取實體的位置、材質等信息,并交給GPU渲染,邏輯線程需要更新實體的位置、材質、骨骼動畫等數據,很顯然一個寫入一個讀取,這為我們實現一個沒有線程同步的多線程3D渲染系統提供了可能。
為了讓讀取和寫入不需要Lock,我們需要為每一份數據設計一個帶有冗余緩存的結構,讀取線程讀取的是上次寫入完成的副本,而寫入線程則向新的副本寫入數據,并在完成后置上最新標記,置標記的操作為原子操作即可。以Vector為例,這個結構大致是這樣的:
struct VectorData

{
Vector4f m_pVector[DATACENTER_CACHE];
int m_iIndex;


VectorData()

{
memset( m_pVector, 0, DATACENTER_CACHE * sizeof(Vector4f) );
m_iIndex = 0;
}


void Write( Vector4f& rVector )

{
int iNewIndex = m_iIndex == DATACENTER_CACHE - 1 ? 0 : m_iIndex + 1;
m_pVector[iNewIndex] = rVector;
m_iIndex = iNewIndex;
}


Vector4f& Read()
{
return m_pVector[m_iIndex];
}
};
當然我們可以用模板來寫這個結構,讓其適用于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%,而使用多線程的情況下,幀數完全沒有變化!
如果考慮使用多線程優化,最容易想到的就是采用平行分解模式,將骨骼動畫計算和粒子計算寫成兩個for循環,然后用OpenMP將其多線程化,但事實上這樣并不會提高多少效率,這兩者計算仍然要阻滯渲染幀,線程的創建也有一定的消耗。于是我想到了一種極端的解決方案,采用任務分解模式,將渲染和邏輯完全分離到兩個線程去,互不影響,當然這樣線程同步會是大問題,畢竟線程的數量和BUG的數量是成正比的。
我們首先來分析下這兩個線程分別需要做什么工作,需要那些數據。渲染線程需要獲取實體的位置、材質等信息,并交給GPU渲染,邏輯線程需要更新實體的位置、材質、骨骼動畫等數據,很顯然一個寫入一個讀取,這為我們實現一個沒有線程同步的多線程3D渲染系統提供了可能。
為了讓讀取和寫入不需要Lock,我們需要為每一份數據設計一個帶有冗余緩存的結構,讀取線程讀取的是上次寫入完成的副本,而寫入線程則向新的副本寫入數據,并在完成后置上最新標記,置標記的操作為原子操作即可。以Vector為例,這個結構大致是這樣的:































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