Sunstone dev log 17: multisampling
I enabled multisampling. The render looks a lot more polished now:
Unfortunately each frame got ~4x more expensive to render. Without multisampling, Bistro renders at ~20FPS. With 4x MSAA it’s running at ~5FPS. I think that means my renderer is fragment-bound.
I suspect that there’s a lot of redundant fragment shading, and that occlusion culling would help. But before I try that, I want to measure the extent of the issue. RenderDoc’s overdraw overlay doesn’t measure what I want; there are pixels that it marks having a single draw in the render pass, but these pixels are shaded many times according to the pixel history. So I’ll have to add my own fragment shader overdraw recording. If the average per-pixel overdraw is greater than 2 (with MSAA off), then occlusion culling could at least double the speed of fragment shading. The question then is whether the time taken by occlusion culling is paid for by the decrease in fragment shader calls.
What I built
- Cleaned up model loading code
- Fixed camera controls
- Fixed frame timer
- Added multisampling
What I learned
Swapchain images aren’t multisampling compatible.
When I enabled multisampling, I still used my swapchain image as the render pass colour attachment. Vulkan didn’t like this. I needed to use a different colour attachment that could hold the number of samples I needed, and then have the render pass “resolve” into the swapchain image by averaging the samples in the multisampled colour attachment.
Next steps
- Measure pixel overdraw
- Shade in physical units