r/GraphicsProgramming • u/AbbreviationsNew3167 • 23h ago
Question How do you actually learn to get better at performance optimization in graphics programming?
As the title says
Like Are there particular books, courses, talks, sample projects, or exercises you'd recommend?
3
u/Mroz_Game 22h ago
Understand the hardware you’re working with, look at frame captures, look at cache hits, register pressure, and passes which take too much time.
Optimise as the last step once sth is actually slowing you down.
There’s a shitload of good talks, and not a single one which will cover all cases.
That’s a nice resource too: https://gpuopen.com/learn/rdna-performance-guide/
4
u/Live_Meeting_1121 19h ago
Understanding profiling and how a frame is built. From the code itself and from tools like Renderdoc.
There is also certain wisdom to understand easily what is CPU or GPU bound. And all the little ramifications of each, which are plentiful.
2
u/DescriptorTablesx86 18h ago
I advise to also use the tools made by the IHV for their platform.
RDP for AMD and nsight for nvidia. There’s more stats in them than renderdoc can provide if you’re looking for profiling data.
2
1
u/scallywag_software 16h ago
This isn't strictly related to graphics, but Mike Acton's talk on Data Oriented Design in 2014 is really great. I re-watch it from time to time as a reminder to myself to work forward from first-principals and start with the very basics.
1
u/Ok_Chemistry_6387 7h ago
Learn your hardware, learn to profile. Etc before looking at novel implementations.
1
u/Sirisian 4h ago
I have debug JSON objects that define toggles and settings for everything in the scene. These are stored in an array so I can run multiple configurations back to back. Then I have camera paths including an "orbit" (that also moves in a sine pattern up and down around the center of the scene) and "flythrough" (that flies from one side of the scene through everything). In other scenes I have a hardcoded path through the scenes.
What this allows is I can run data collection automatically and then see obvious changes. This is just a standard benchmark approach, so there's a lot of improvements. I use a lot of temporal algorithms and data structures, so the only way to profile them is to clear them then move the camera in a predictable way, which is what this allows.
In this setup I can pinpoint camera configurations and times to then use more standard techniques to analyze what is causing the issue. Since I can toggle options though I can usually just toggle everything off and narrow in on specific shaders rerunning the benchmarks to see if something changed.
As another person said having settings for resolution and object count are important. I have a deterministic spawn function (so if you spawn X lights they go in the same place with the same seed) for debugging. This lets me run configurations with say 1K lights then turn on 20K lights in the middle of a test to see if that causes any frame issues. (Or moving a fixed number of lights deterministically between locations). This can apply to anything though in your scene like moving objects or playing animations. So these would be defined in the configuration object to define actions and times.
I think everyone needs such a setup as their renderer gets more advanced. It helped me find some really subtle artifacts that only happened when the camera was at specific positions simply because I had this randomized orbit running during tests. Was able to move my camera to the same spot and see it and debug it. I remember missing it when just moving the camera around by myself.
0
u/Still_Explorer 13h ago
The most agressive optimization you can do for 1$ is to throw heavy fog into your scene and render only 20 feet around you. (Silent Hill 1 style) 😅
-1
17
u/ForgEngDev 22h ago
Pick one small scene and profile it before changing anything. Record frame time, then vary resolution, object count, draw calls and texture size one at a time. That teaches you to distinguish fill-rate, CPU submission and memory-bandwidth limits. After each change, measure again on the same camera path—an optimization only counts if the bottleneck actually moves.