I am a huge fan of all traditional forms of supersampling, intra-frame-only anti-aliasing techniques. The performance cost begins to make sense when you realize that these techniques are essentially perfect for the general case. They actually increase the information content of each pixel within each frame. Many modern techniques rely on multiple consecutive frames to build a final result. This is tantamount to game dev quackery in my book.
SSAA is even better than MSAA and is effectively what you are using in any game where you can set the "render scale" to a figure above 100%. It doesn't necessarily need to come in big scary powers of two (it used to and made enablement a problem). Even small oversampling rates like 110-130% can make a meaningful difference in my experience. If you can afford to go to 200% scale, you will receive a 4x increase in information content per pixel.
The output of a single pixel shader invocation is duplicated 2, 4 or 8 times and written to the MSAA surface through a triangle-edge coverage mask, and once rendering to the MSAA surface has finished, a 'resolve operation' happens which downscale-filters the MSAA surface to the rendering resolution.
SSAA (super-sampling AA) is simply rendering to a higher resolution image which is then downscaled to the display resolution, e.g. MSAA invokes the pixel shader once per 'pixel' (yielding multiple coverage-masked samples) and SSAA once per 'sample'.
if i render a linear gradient at increasingly higher resolutions, I certainly am not creating infinite information in the continuum limit obviously
[0] eg https://docs.nvidia.com/gameworks/content/gameworkslibrary/g...
Because before I clicked on the article (or the comments), that's the only sense I could make of the expression "d3d12" — rolling a d12, d3 times.
shmerl•1h ago
rahkiin•1h ago
pjmlp•1h ago
HexDecOctBin•17m ago
And the world would have been a better place. All we needed in OpenGL 5 was a thread-safe API with encapsulated state and more work on AZDO and DSA. Now, everyone has to be a driver developer. And new extensions are released one-by-one to make Vulkan just a little more like what OpenGL 5 should have been in the first place. Maybe in 10 more years we'll get there.
kg•12m ago
HexDecOctBin•9m ago
flohofwoe•56m ago
Competition for 3D APIs is more important than ever (e.g. Vulkan has already started 'borrowing' a couple of ideas from other APIs - for instance VK_KHR_dynamic_rendering (e.g. the 'render-pass-object-removal') looks a lot like Metal's transient render pass system, just adapter to a non-OOP C API).
dotnet00•14m ago
Considering that DX12 made it out earlier, and it took some time for Vulkan to finally relax some of its rules enough to be relatively easy to use efficiently, I think it just lost momentum.