Daniel Evans

Improving OpenGL Performance

2017-10-08T00:00:00+00:00

The in game performance of OpenRW was worse than it should be. I investigated why and made great performance improvements on an important platform: laptop GPUs. This post covers the investgation and the changes made.

Testing Performance

OpenRW has a “test mode” that spawns several vehicles and pick-ups in a central location. Performance in this spot isn’t great, so I started there. I took samples from two angles, looking at the horizon and looking at the ground. There was quite a difference in performance between the two situations.

View	Frame time	Draws
Ground	7.3 ms	191
Horizon	17.7 ms	1035

CPU Profiling with Perf

To try and understand what is happening I began profiling with perf. I ran perf in the following way, which spawns sleep but records samples from rwgame (the process name for OpenRW), an easy way to record for a fixed length of time.

$ perf record -p $(pidof rwgame) sleep 15

Once the process exits, perf record writes out a file containing the samples it took. The data can be viewed in the terminal by running perf report. I recorded a few sessions looking at the horizon, and the report was roughly the same each time.

The top two most sampled methods are within the Intel GPU driver, followed by bullet (I’m not sure what causes the odd symbol names like 0x0000000000007e45). It is clear that a lot of time is spent in the driver, more than I would expect for such a simple scene.

Since the CPU profile shows a lot of time in the driver, I suspected that the OpenGL usage was far from optimal. To see what was happening between OpenRW and the driver, I needed to take a look at the GL calls. There’s some good tools for this these days: RenderDoc and apitrace being the most portable.

OpenGL debugging with apitrace

OpenRW doesn’t do anything complicated so using apitrace to inspect the raw OpenGL calls is easy enough. I captured a trace of the Horizon scene like so:

$ apitrace trace -o test_mode.trace ./rwgame/rwgame -t

The trace can be viewed with the GUI trace viewer QApitrace, or inspected with command line tools.

This trace shows a couple of issues:

Enable(GL_BLEND) is called repeatedly to no effect: a bug.
BufferData is called for each draw to upload data: expensive.
Each draw requires a new VAO be bound: expensive

State Caching

Calling Enable(GL_BLEND) repeatedly isn’t going to do us any favours, and could be obscuring some bugs elsewhere. This is the first thing I decided to fix as it shouldn’t have been happening in the first place. The rendering system is intended to cache the set state and only change it if we have to, but the method responsible, OpenGLRenderer::setBlend(bool) didn’t even check if we were trying to turn it on, it just called glEnable(GL_BLEND) no matter what. I corrected that and immediatley a few things broke:

The issue was just down to the map and particle system not enabling the blending state, even though they relied on it. This was overlooked previously because the bug in setBlend left the state enabled. After updating those call sites to set the correct state, it was fixed.

Buffer Updates

The next issue on the list is the per-draw data updates. Calling BufferData for each draw is expensive. I consulted the “Approaching Zero Driver Overhead” presentation for guidance, and decided to implement a simple solution:

Determine the largest UBO size available from the driver.
Decide how many draw calls worth of data can fit inside a single UBO.
Then, Per-Draw:
1. If we have run out of space in our UBO, reset the counter and get new storage with BufferData.
2. use MapBuffer with the offset for our current draw data, copy the data into the buffer and unmap.
3. Bind the UBO at the offset for the current draw, and Draw.

This isn’t as extreme as using persistent mapping like the AZDO presentation suggests, but should at least avoid some of the pressure of re-allocating storage for each draw that the driver is still trying to use. It also has the benefit of not requiring OpenGL 4.0, unlike persistent mapping.

The result is a significant increase in performance, slicing several milliseconds off most frames. Revisiting the original test shows what impact the buffer update strategy has, a pretty reasonable 30% improvement.

View	Frame time	Draws
Ground	6.7 ms	250
Horizon	12.2 ms	1063

What’s Next

While 30% is a modest improvement in performance, there is more that can be gained by applying some further changes to how rendering works:

Allocating one buffer for multiple vertex and index data, to reduce buffer changes.
Copying draw data to buffers in larger batches.

But these can wait. Performance has improved enough already to make OpenRW playable so it is more important to fix gameplay issues and make sure it’s actually worth playing.

Texture Containers

2017-04-04T00:00:00+00:00

Textures, Filtering and Mipmaps

When writing simple applications using OpenGL, it’s not uncommon to use a library such as stb_image or SOIL to load a PNG or JPEG image as a texture. This is nice and convenient. The ease of use doesn’t come with downsides, however. The compression used for JPEG and PNG leaves the image in a format unsuitable for the random-access required by texture sampling on the GPU. To make these images usable, they are decompressed before being uploaded. The decompression step, while quick, can add up if you have a large number of textures or a very tight budget. For example if you are streaming data in-game, naïvely decompressing many JPGs or PNGs will eat into your 16.6ms budget.

Unless you are rendering a screen-sized texture onto a screen-sized quad, each pixel in the image is unlikely to cover 1 pixel on the screen. To improve the quality of the texture when viewed smaller, larger, and at shallow angles, filtering techniques are used to get a plausible colour for each sample. Mipmaps are the most important for this post.

The idea behind mipmaps is that rather than have a single screen pixel cover 10s or more texture pixels, a smaller version of the texture is used that has better coverage, requiring fewer samples. Thus each texture is not an individual image, but a series of mipmap levels, each half the size of the previous level. To give an example, a texture that’s 256x256 pixels, could have mipmaps for 128x128, 64x64, 32x32, and so on. If the view was facing directly at a plane with this texture (let’s say it’s a brick wall), then depending on the distance and viewport size moving away from the wall would select progressively smaller mipmaps for use to keep the ratio of texture pixels to screen pixels reasonable.

Usual image formats don’t support storing these mipmap chains. When loading a JPG or a PNG, mipmaps must be generated by resizing the original image repeatedly for each required mipmap level. That’s no problem if you only have 10 textures, but if you have 100s of textures or need to stream in textures at run-time, then spending time generating these smaller images will be something worth reducing.

Texture containers are a solution to these problems. Not only do they store texture data suitable for direct use as textures, they also store mip-map and array data. This means a single texture container can store all the data required for an entire texture, no matter it’s size, number of mipmaps, array layers or cubemap faces. Generating mipmaps offline is important if you use compressed textures, as it’s generally impractical to generate compressed textures at runtime.

Container formats

The most common texture container formats in use that store data compatible with D3D, OpenGL or Vulkan, are the Khronos Texture format (KTX) and DirectDraw Surface (DDS).

Khronos Texture (KTX)

Khronos Texture is a Khronos Group standard for storing textures intended for use with OpenGL and OpenGL ES. The specification for the format is available via Khronos. It contains format information directly compatible with OpenGL and OpenGL ES enumerations. Also included is the ability to store application specific key-value data within the file.

The specification provides a good overview of the format and the expected values for each of the header fields. The format can store 1D, 2D, 3D, Cubemaps and Array Textures, along with any number of mipmaps for these textures. This makes it ideal for storing almost any kind of texture you could want.

The texture data is described in theglType, glFormat, glInternalFormat, and glBaseInternalFormat header fields. These should match up with the parameters to the gl[Compressed]Tex[Sub]Image*D calls used to submit each texture mipmap level’s data.

DirectDraw Surface (DDS)

Despite DirectDraw being long deprecated, the DDS format is still in common use for storing textures used with Direct3D. Originally only 2D textures were supported, but the D3D10 header extension added support for texture arrays and D3D10+ features. The format is partially documented along with expected values on MSDN, useful for integrating DDS into your pipeline.

For loading DDS in D3D11, there is a deprecated function, D3DX11CreateTextureFromFile, which is no longer available in Windows Store apps. DirectXTK has a replacement, DDSTextureLoader that can be used instead.

Use containers

Since KTX is somewhat better specified that DDS, I would recommend using it over DDS. Howerver, as long as you use a sensible format that simplifies storing and loading, you should benefit from the increased simplicity and reduced loading times. There is an official KTX library libktx for working with KTX files. More information about this is available on the Khronos website.

clang-format

2017-02-22T00:00:00+00:00

Reducing the effort required to keep code style consistent is important, because doing so helps readability, and the task is not very interesting. clang-format is a great tool for re-styling entire C++ files, or even small sections, automatically. It provides a wide array of configuration options, listed here, and some default configurations for style guides from LLVM, Google, etc.

The OpenRW project provides a clang-format configuration that applies a reasonable style to the codebase. While using it I’ve found a few useful things that improve my workflow, and have some ideas of what could be improved.

Trailing comma in list initialisation

Leaving a trailing comma in a C++ list initialisation is a useful pattern for lists that are likely to change. As you don’t need to change the previous entry if you add another element.

clang-format takes this into account by breaking each element onto its own line if there is a trailing comma after the last item. This greatly improves readability in larger lists and simplifies diffs when changes are made.

std::vector<mytype_t> kMyElements{
    {
        "foo",
        {
            "bar", "baz",
        },
    },
    {"one", {"two", "three"}},
};

The 2nd element has been squashed down to one line, despite being almost exactly the same number of symbols as the first. This is great for nested structures and long lists that are difficult to read when not expanded.

QtCreator integration

QtCreator is my daily driver, and so it would be useful to have a hotkey for applying clang-format to a block of code. The QtCreator developers seem to feel the same way, since it comes with a plugin called Beautifier. This can apply a few different code styling tools to open documents, including clang-format.

To enable it, just click Help > About Plugins and tick Beautifier, then restart QtCreator. You can then run clang-format from the Tools menu. Unfortunatley you can’t select a clang format configuration file to use, but you can copy the configuration into the Tools > Options > Beautifier > clang-format screen.

I find it’s useful to have a keyboard shortcut to continually re-format the code I’m working on. To set up a hotkey for this, click on the Environment > Keyboard tab, then search for clangformat. I typically use Ctrl+? as it doesn’t conflict with anything else.

Enforcing style in pull requests

As the number of contributors to OpenRW increases, reducing the burden on those reviewing pull requests is critical. Nit picking about style is something nobody should expend effort over, so I would like to have clang-format be part of the continious integration process.

I’e not yet implemented this in the OpenRW project but I can imagine a system that I would be reasonable to use. Before the code is built on travis, a script should run that applies clang-format to the lines changed between the master and the branch commits. If this script produces any output, then the build will be marked as failed and the user should get a useful diagnostic of what they need to change to fix the style.