1 of 58

Tightening Up the Graphics: Tools and Techniques for Debugging and Optimization

Elizabeth Baumel

2 of 58

Overview

Computer graphics AND YOU
Common problems
What those problems might be and what to check for
Time to break out the TOOLS
Debugging with Renderdoc
Performance and Profiling with GPU PerfStudio
Things that make your frame slow

3 of 58

Who this talk is geared for

Done games, but not graphics
New to graphics
Maybe you’ve done some graphics, but not for games
One time a game you were playing had a hilarious glitch and you want to know what happened
Want to write a corrupter…?

4 of 58

Computer Graphics for Games

You have 16-33 milliseconds per frame. (less for VR)
You will have to make tradeoffs
CPU and GPU work together
The GPU is powerful, but not all-powerful.
GPUs act differently than CPUs and can be ~mysterious~.

So what’s the deal with computer graphics?? Without getting into a huge amount of detail, let’s talk about what you, the game programmer, need to know if you’ve never done graphics before. You have a very short period of time to get everything done for each frame. For example, if you’re shooting for 60 FPS, you have 16ms. If you’re doing VR, you’re probably shooting for a higher frame rate so you have even less time. Making the most of this time is a game of tradeoffs between fancy techniques and speed. GPUs are very good at what they do and I’m sure you’ve heard a lot about off-loading tasks to the GPU, which in a lot of cases really can be great, but GPUs are hardware with limitations like any other. One of those limitations that you will notice, especially as a someone new to graphics programming is that debugging on them can be quite a bit different than debugging code on a CPU.

5 of 58

Graphics (D3D11) Pipeline

Input Assembler

Vertex Shader

Hull Shader

Tessellator

Domain Shader

Geometry Shader

Stream Out

Rasterizer

Pixel Shader

Output Merger

Memory Resources

Textures

Buffers

Render Targets

Constants

DepthStencil

...

CPU Side

6 of 58

Graphics (D3D11) Pipeline

Input Assembler

Vertex Shader

Hull Shader

Tessellator

Domain Shader

Geometry Shader

Stream Out

Rasterizer

Pixel Shader

Output Merger

Memory Resources

Textures

Buffers

Render Targets

Constants

DepthStencil

...

CPU Side

After you’ve set everything up on the CPU side, that’s stuff like loading up your models’ vertices and the textures you need and stuff like that (click) (click) (click)

You send it down to the GPU where the Input Assembler pieces your meshes together.

Once it’s done doing that, it goes to the Vertex Shader stage. This is a stage you’ll always deal with since it feeds into the rest of the pipeline. It basically moves vertices around in the way you tell it to, be it for simple transforms into screen space, or for vertex skinned animation.

From there, once your vertices have been transformed, they can go into the first part of the optional tessellation stages, which is the hull shader stage. This takes your vertices and makes control points for the tessellator to use. Then the tessellator takes those control points and outputs topology into the domain shader stage, which then outputs geometry data. From there, you can optionally send that geometry into the geometry shader to maybe get out MORE geometry. Stream out lets you send that geometry data around for another go through the pipeline. After you’re done fiddling with your geometry data, it all goes to the rasterizer to get clipped, culled, and a whole bunch of other stuff I couldn’t fit onto this slide before getting turned into pixels. The pixel shader operates on the output of the rasterizer and is the other non-optional programmable shader stage. After you’ve done your cool lighting effects in the pixel shader, those pixels get fed to the output merger, which is the last stop before those pixels get output to a render target or the back buffer so you can actually see your frame.

7 of 58

Common Graphics Problems

Blank screen

Or: things not drawing that should be

Flickering
Corruptions
Shader bugs
S l o w n e s s

8 of 58

Blank Screen Quick Checks

Is your math right?
Where’s your camera?
Is your geometry getting culled?
Are you clearing?
Are you actually drawing anything?

¯\_(ツ)_/¯

Blank screens can be really frustrating, since there’s nothing to look at or see that might help you debug what’s going wrong. Here are a few quick things to check before diving down the rabbit hole if you’re not seeing anything at all. First of all, check to make sure your math is right. Sometimes your camera just isn’t pointing at the right thing or it’s really distorted, or your objects aren’t where you expect because you got your linear algebra wrong. You may have to break out ye olde pen and paper. Maybe your geometry is all getting culled. Where are the bounds of your view frustum? Is your geometry in front of your near plane or beyond your far plane? Do you have backface culling on and all backfacing geometry? Are you clearing at the wrong time? Are you even calling your draw call? I’m serious, make sure you’re actually calling Draw().

9 of 58

Flickering

Timing is wrong somewhere
Double-buffering correct?
Are multiple resources touching the same memory?
Dependencies?

pretend this is flashing

Once you’re actually drawing stuff, you may encounter flickering of your whole screen or maybe just parts of it. A lot of the time, this is a synchronization issue where you’re just not waiting long enough for something to finish before using it, or doing things in the wrong order. A classic example is if you’re not double buffering your frame right or at all. In the correct case, you render the current frame you’re working on into what’s called the back buffer, which gets flipped to be the new display buffer at the end of the last frame. If you’re using a single buffer or flip at the wrong time, you can see flickering or tearing. Sometimes you may find that you need to double buffer more than just the frame, or in some cases you might need to triple buffer. Sometimes you need more than one thing to read and write to the same memory, and if that’s not synced properly, you can see flickering or corruptions. Think about what each piece of your frame depends on and that if you have a chain of things that depend on each other, that they’re synced properly.

10 of 58

Corruptions

What’s getting corrupted?
Geometry?
Textures?
Render targets?
Depth buffer?
Constants?
Something else?

11 of 58

Geometry Corruptions

Triangle horrors
Mesh holes
Messed up orientations
Missing geometry
No geometry at all

12 of 58

Texture Corruptions

Rainbow missingno
Bizarre stretching
Wrong color
Some legit data + artifacts

Texture corruptions can manifest in some truly interesting abstract art kind of ways, especially if you’re using a texture for something other than a color map on a mesh. Sometimes you’ll see rainbow missingno-looking garbage, which can be due to actual garbage data in the texture, or just a case of interpreting legitimate data incorrectly. To give you an example, one time I had an issue with a cube map coming up partially garbage and partially black, so the reflections in this one scene were garbled rainbow puke with black chunks. After some digging, it turned out that the textures themselves were perfectly fine, block-compressed cubemaps, but they were being read in as uncompressed linear textures. It was sort of like if you paste an image into notepad and get a wall of incomprehensible nonsense; the data is valid, but you’re reading it wrong. In the case of actual missingno, you’re just looking at pure garbage data. Sometimes you can see a texture stretched in one direction or another, and sometimes a texture looks mostly okay, but it’s kind of the wrong color or it has some artifacts on it. and that’s when you should start thinking about what’s happening with your constants or what’s going on in your pixel shader.

13 of 58

Depth and Render Target Horrors

Smearing - Make sure to clear!!
Frame leftovers
Wrong order of objects
Translucent stuff wrong

14 of 58

Constant Buffer Corruptions

Might not be your resources
Shader constants can get wrecked too
Could also be a synchronization issue
Don’t trash what you’re not done with!

15 of 58

Shader color “printf” debugging

Quick, no tools involved
Good for sanity checks
Best for PS
Can pass thru other things too

16 of 58

Use the D3D debug layer

Catches a lot of issues that cause these horrors

Parameter & consistency validation
Shader linkage & resource binding validation

Helps you debug crashes
Lets you dig around directly in your code
No equivalent in OpenGL :(

17 of 58

Down the Rabbit Hole

Where in the pipeline does the badness start?
Which resources are involved in the badness?
How are you messing up the resources?
How do you fix it?

18 of 58

Frame Capture and Analysis Tools

AMD GPU PerfStudio, Intel GPA, Renderdoc, etc.
API calls, frame events
Resource viewer
Shader Debugger (sometimes separate)

19 of 58

Renderdoc

Free, open source
DirectX 11, OpenGL
Similar to other tools (PIX, Razor, etc.)
Simple to use

20 of 58

Renderdoc

Timeline

API Calls

Specify exe to debug here

Events

21 of 58

Renderdoc

Timeline

API Calls

Pipeline State

Events

22 of 58

Timeline

API Calls

Mesh Output

Events

(draw calls)

23 of 58

24 of 58

25 of 58

26 of 58

Render Passes

Current pass’s clears and draw calls

Corresponding API calls

27 of 58

28 of 58

29 of 58

30 of 58

31 of 58

32 of 58

33 of 58

34 of 58

35 of 58

36 of 58

Shader Debugging

Kind of similar to CPU debugging
Step through shader assembly

Need to compile with debug info for shader source

Not all shader debuggers have edit and continue

37 of 58

38 of 58

39 of 58

Sometimes it’s not your fault (but usually it is)

Other people’s bugs can appear in:

Engine
Compiler
API
Driver
Hardware!

40 of 58

Profiling

Your game has slow parts - I guarantee it!
Where are they?
Who’s taking longer?

CPU or GPU?

Only one way to find out.

41 of 58

Profiling

Profiling from the CPU side code

Wrap draw calls in timing blocks
Do a lot of testing
DX11 timestamps, Unreal stats, RAD telemetry

Graphics profiling tools

GPU PerfStudio
RTTV, PIX

There are a TON of tools out there for profiling, you can go simple with built in timer queries in DX11 or you can use something like RAD telemetry which has a visualizer. If you’re working on something on PS4 or Xbox, you have access to some really cool tools that can poll the GPU directly and give you some really awesome, detailed information about which parts of the pipeline are taking the longest and which parts of the GPU are getting used and in which ways. The main thing is you need to find out just how many ms each part of your frame is taking. I also want take this opportunity to point out that frame rate, as a measure of speed, is a terrible unit. The number of frames you can get done in a second doesn’t tell you anything about how fast a single frame is, since stuff from both the CPU and GPU can affect it. FPS is a target, milliseconds are for measurements.

42 of 58

GPU PerfStudio

Frame Profiler
Frame Debugger, Shader Analyzer
DX12!!
Tiny bit more complicated than RenderDoc

43 of 58

44 of 58

45 of 58

GPU PerfStudio

Lots of counters!
See cool and useful stats on your frame
Quantitatively see stuff like

Overdraw
Shader invocations
Primitives culled
Data read

46 of 58

Draw Calls

Times PS was invoked

# prims rendered

# prims sent to rasterizer

# samples that passed depth stencil

# verts/prims read by IA

Times VS was invoked

47 of 58

48 of 58

Performance Issues

Overdraw
Inefficient data layouts
Content issues
Too many tiny triangles
Bad shaders
Anti-aliasing
Too much context switching
Blood curses
And many more!

49 of 58

Overdraw

Slow because you’re drawing things you don’t need to
Cull as much as you can

Depth pre-pass, occlusion volumes, etc.

Use Hi-Z!
Opaque stuff first
Be careful with depth writes + alpha/discard

You’ll bypass early Z
Using Late Z -> many more pixels shaded

Hi-Z

Early Z

Pixel Shader

Late Z

Overdraw is a problem because it’s effectively time you’re wasting drawing stuff that’s going to be behind other stuff. If you have expensive pixel shaders, you’re going to want to make absolutely sure that every pixel you shade is actually being seen. The way you handle this is by making sure you’re culling as much as you can. That means using occluder objects, depth prepasses, occlusion culling, anything that will limit the things you draw to what you can actually see. Once you’ve culled as much as you can before you get to the actual depth test stage, make sure you’re effectively using the depth hardware. Do your opaque rendering first, then anything that needs an alpha test. Use Hi-Z which is also known as hierarchical Z or Z cull, which is basically just a coarse rejection. If a triangle makes it past hi-Z, it goes to early Z, which is the last stop to NOT send things to the pixel shader. If you’re doing depth writes along with your alpha test or discards, you’re going to skip early Z. Also be really careful with writing to UAVs because then you end up skipping Hi-Z as well.

50 of 58

Textures

PLEASE USE MIP-MAPPING
The right format for the right job

Don’t use highest precision if not needed
Consider using block compressed formats

Filter wisely

Trilinear filtering twice as expensive as bilinear
Anisotropic filtering N times as expensive, depending on sample count

Textures lookups take time and that means you want to make the most out of your caches. You know what’s good for caches? Mip-mapping. It also just looks better, and eliminates artifacts. It’s pretty old technology at this point so there’s no excuse not to be using it. When creating your textures, figure out what format is the best for what you’re using that texture for. Is it a character’s face or a terrain normal map or a lookup texture for some other effect? If you don’t need a ton of precision, don’t use high precision textures. It’s not work the memory. Another way to save memory is using block compressed textures. When you’re filtering your mipmapped textures, you’ll have to evaluate the quality versus speed tradeoff you need. Triliniear is twice as expensive as bilinear filtering, and anisotropic, while very pretty, gets more and more expensive as your sample count goes up.

51 of 58

Shaders

How long/complex are your shaders?
Some instructions are slower than others
Don’t use more registers than you need
The compiler will sometimes betray you

Look at the asm

I/O to GPU adds up fast (lol bandwidth)

52 of 58

Vertex Shaders

Minimize your vertex attributes!
Optimize your meshes
Complicated shaders (skinning, etc.)
Use an LOD system (test a lot)

struct VS_INPUT

{

float4 Position : POSITION;

float2 Texcoord : TEXCOORD0;

float3 Normal : NORMAL;

float3 Tangent : TANGENT;

float3 Bitangent: BINORMAL;

};

Minimize the number of attributes you’re passing into your vertex shader. You will see this will become a bit of a theme. Try to optimize your meshes for good cache efficiency. Vertex shaders aren’t usually the first place you think of when you look for bottlenecks, but If you have complicated shaders like for advanced skinning or something, your vertex shader could be a bottleneck. If you don’t have an LOD system in place, seriously consider using one. It’s not a cure-all, but there are a lot of cases where it can really help your performance by reducing the number of triangles you need to draw. Rendering high resolution meshes that are far away is a huge waste of resources and cause be a bottleneck VS, but also cause more trouble farther down the pipeline. Tiny, subpixel triangles are the enemy.

53 of 58

Tessellation

Disable it when you don’t need it
Minimize vertex output attributes
Do your own culling

HW culling happens later in the pipeline, at the Rasterizer

Don’t overtessellate!!

Subpixel triangles are BAD

Undertessellation will give you artifacts

54 of 58

Geometry Shaders

Probably better off doing it on the VS in most cases
VS instancing
If you must use GS, minimize output attributes
Why GS is slow: http://www.joshbarczak.com/blog/?p=667

55 of 58

Pixel Shaders

Often a bottleneck, but not always (sometimes tess or CS)
See if you can early-out with discard
Limit your trig and other expensive instructions

cos, rcp, integer mul and div, etc.

Minimize attributes sent from earlier stages
Texture fetches add up

minimize them and cluster reads/writes

56 of 58

Compute Shaders

Useful for general purpose computing, stuff that’s too slow in other stages
Powerful, but can be tricky - They are not a cure-all!
Big pile of threads that share memory
Output to unordered access view (UAV)
Can do atomic operations

57 of 58

Wrap Up

Graphics is cool and messy and involves lots of detective work
Try many things, testing is the way to enlightenment
Use the tools!
Make things easy for the GPU and you will be rewarded

58 of 58

Questions?

@Icetigris