June 8, 2012

Doom3 Source Code Review: Profiling (Part 4 of 6) >>

XCode comes with a great tool for profiling: Instruments. I used it in sampling mode during a playing session (removing the game loading and level GPU pre-caching altogether):

Overview


The high level loop shows the three threads running in the process:

 

Main Thread

The Doom 3 MainThead runs...QuakeMain! Amusingly the team that ported Quake 3 to Mac OS X must have reused some old code. Inside the time repartition is as follow:



 

Game Logic

The gamelogic occurs in gamex86.dll space (or game.dylib on Mac OS X):

The game logic account for 25% of the Main Thread time which is unusually high. Two reasons:



 

Renderer

As previously described the renderer is made of two parts:


The load distribution is pretty much even and it is not that surprising since:

 

Renderer: Frontend

Renderer FontEnd:

No surprise here, most of the time (91%) is spent uploading data to the GPU in VBOs (R_AddModelSurfaces). A little bit of time (4%) is visible when going through areas, trying to find all interactions (R_AddLightSurfaces). A minimal amount (2.9%) is spent in Visual Surface Determination: Traversing the BSP and running the portal system.

 

Renderer: Backend

Renderer BackEnd:

The backend obviously triggers a buffer swap (GLimp_SwapBuffers) and spend some time synchronizing (10%) with the screen since the game was running in double buffering environment. 5% is the cost of avoiding totally overdraw with a first pass aiming to populate the Z-Buffer first (RB_STS_FillDepthBuffer).

 

Flat stats



If you feel like loading the Instruments trace and exploring yourself: Here it the profile file.

Comments

 

Fabien Sanglard @2012