User:Hannu Hanhi/Perfstats

From SRB2 Wiki
Jump to navigation Jump to search

WIP perfstats documentation page

Perfstats shows various measurements related to the performance of SRB2 on your computer.

It includes timing measurements, which tell how long the game spent doing particular tasks, and counters, which count various things that are relevant for performance. All timing measurements are shown in microseconds. 1000 microseconds is 1 millisecond and 1000 milliseconds is 1 second.

In order to keep the game's normal frame rate of 35 frames per second, every frame and tic must be completed within ~28 571 microseconds.

perfstats 1 - Rendering

This page shows graphics rendering related statistics. Different measurements are shown in Software and OpenGL modes.

Both modes show the frame time on top. This measures the time taken between the latest and the previous frame being shown on screen. Frame time (microseconds per frame) is the inverse of FPS. (frames per second) When the game is running normally, this value will be roughly 28 500 microseconds.

Next is total time spent in 3d rendering. This measures total time spent rendering the current view of the level. This measurement is not shown if you're not in a level. Various submeasurements about different 3d rendering tasks are shown under this.

UI rendering time is shown below 3d rendering measurements. This measures the time spent in rendering the HUD and menus of the game. This also includes the time spent in Lua HUD hooks.

The total time spent in game logic calculations is also shown in the bottom. Perfstats 2 has more detailed measurements about game logic.

Software

In Software mode, the following 3d rendering measurements are shown:

RenderBSPNode: Iteration of the level's BSP tree. Walls are drawn and planes, sprites and FOFs are collected. High values could be a sign of a highly complex area in a level.

R_ClipSprites: The sprites collected in the previous stage are clipped against walls, so they cannot be seen through them. High values could be a sign of a large number of sprites and walls in the view.

Portals+skybox: All rendering of portal and skybox contents.

R_DrawPlanes: The drawing of floors and ceilings. High values could be caused by slopes and/or non-power-of-two floor/ceiling textures occupying a large amount of the screen surface area.

R_DrawMasked: Sprites FOFs and midtextures are sorted and drawn. High values could be caused by high map complexity, or a large amount of translucent surfaces. Sloped and/or non-power-of-two-textured FOF floors/ceilings can also increase this value.

Other: Everything else that was not included in the measurements above.

The following counters (shown in blue text) are shown on the second column:

BSP calls: The number of recursive calls to RenderBSPNode. This shows the complexity of the current view of the level.

Sprites: The number of sprites drawn to the screen. (check??)

Drawnodes: The number of sprites, FOFs and midtextures sorted and drawn to the screen.

Polyobjects: The number of polyobjects drawn to the screen.


OpenGL

NOTE: Most rendering time measurements can be skewed in OpenGL mode. This is because OpenGL drivers can delay the execution of operations until a later stage which is outside of the timed interval. The measurements can have some informational value, but a lot of care should be taken when using them. For example, a slowdown in sprite rendering can manifest inside any other later rendering stage, if the drawing commands for sprites are not handled immediately but delayed until later. GPU time measurements are not available, only the time between various parts of the renderer's C code is measured. The following measurements do not contain OpenGL API calls and can therefore be measured reliably: RenderBSPNode, Drawnode sort, Batch sort, Sprite sort.

In OpenGL mode, the following 3d rendering measurements are shown:

Skybox render: All rendering of skybox contents.

RenderBSPNode: Visible geometry is collected by iterating the BSP tree. High values could be a sign of a highly complex area in a level.

Batch sort: All geometry apart from sprites and translucent surfaces is sorted in an order that tries to maximize OpenGL rendering efficiency.

Batch render: Drawing commands from previously sorted geometry are combined and issued to OpenGL.

Drawnode sort: Translucent surfaces are sorted back-to-front.

Drawnode render: Drawing commands are issued for sorted translucent surfaces.

Sprite sort: Sprites are sorted back-to-front.

Sprite render: Drawing commands are issued for sorted sprites.

Other: Everything else that was not included in the measurements above.

The counters for BSP calls, sprites, drawnodes and polyobjects are included here just like in software mode, but drawnodes only includes translucent surfaces instead of all FOFs like in software mode.

The third column shows the amount of batched polygons and vertices sent to OpenGL. (does not include sprites and translucent surfaces) Next is the number of draw calls generated and the number of unique shaders, textures, polyflags and surface colors in the current view.

perfstats 2 - Game logic

This page contains measurements related to simulating the game world.

The first column contains timing measurements, divided into the following:

P_PlayerThink: Player thinker routines, including Lua PlayerThink hooks.

P_RunThinkers: All other thinkers, for example mobjs and polyobjects. "Main" thinkers refer to various miscellaneous non-mobj thinkers, like doors and elevators. Lua mobj hooks also happen here.

LUAh_ThinkFrame: All Lua ThinkFrame hooks. More measurements about these can be found in perfstats 3.

Other: Everything else that was not included in the measurements above.

The second column shows the number of all thinkers in the map, divided into various categories.

The third column contains miscellaneous counters that can be relevant for performance:

Lua mobj hooks: The number of mobj-related Lua hooks called on this tic. A high number of these can be a reason for Lua-related slowdowns.

P_CheckPosition: The number of times the P_CheckPosition function was called on this tic. This function handles various physics interactions in the game. A high number could be caused by a large number of interactable physics objects on the map and could result in decreased performance on lower end machines.

perfstats 3 - ThinkFrame hooks

This page lists all running ThinkFrame hooks in Lua scripts.

For every hook, the script name and the time spent in microseconds is shown. Multiple hooks in the same script will be shown with the same name, in the order they were registered by the script.

NOTE: Other Lua hooks don't (as of writing) have perfstats pages about them. Some deductions about their performance can sometimes be made from information in perfstats 2.