.png)
2 hours ago
2
While working on Indiana Jones and the Great Circle and later DOOM: The Dark Ages, it became apparent that both titles are particularly sensitive to anisotropic sampling cost on the Xbox Series consoles. This is despite both having very different renderers, Indiana Jones uses what I would best describe as a semi-forward system, while Doom use deferred texturing, with the novel development of a barycentric buffer. (See GPC 2025: Visibility Buffer and Deferred Rendering in Doom the Dark Ages) The fact that both are so sensitive to anisotropic tap count I ascribe partly to the system of layering materials, and partly to the fact that both games use Samper Feedback Streaming (SFS) on Xbox Series consoles. (SFS adds an additional texture fetch to discover what the most detailed mip is in memory for a given texture region, which is then used to limit the access of a subsequent texture read)
As usual, the problem arises due to variation in scene content. Some scenes could afford high levels of anisotropic sampling, while others benefitted from reducing the count to ensure a locked 60hz output. I set about one Saturday (immediately prior to code lock) to attempt to tie anisotropic sampling level to the current dynamic resolution scale, not entirely convinced this was a visually acceptable thing to do.
Most non-engineers would be amazed how much DRS resolution choice can jump around even with a steady camera. A good TAA/super resolution implementation ensures nobody notices per-frame resolution changes. In fact, I think it can help, providing additional temporal information on a macro scale, while sub-pixel jitter provides additional information on a micro scale.
The problem with changing anisotropic sample count is that it’s extremely obvious, visually nasty, and particularly distracting if the count flip flops. The difficulty therefore was to create an algorithm that will change the count, but is reluctant to do so, and will even stick with a setting it considers to be ‘wrong’ rather than change it.
The solution I arrived at is two part; the first is a filter, which is used to ensure the same recommendation for change has been made for a number of frames, less frames the higher the confidence. This on its own however was not enough. The second part of the algorithm is an aid to prevent flip flopping, so if the last change was to increase the anisotropic tap count, increasing it again is easier than switching direction and decreasing the tap count.
This algorithm varied the anisotropic tap count between 1 (bilinear) and 8 on Xbox Series S and between 4 and 10 on Xbox Series X. (10 being in effect is a bias towards 8)
Something I expected I might need to implement was an additional reluctance to up sample unless the camera transform had altered significantly. However, I did not find this necessary, the algorithm has enough resistance to change that in practice, it rarely changes the sample count with a steady camera anyway, and when it does, it’s hard to argue the choice. Anisotropic scaling wasn’t applied to the terrain system as this used different samplers, but likely could have been for additional savings. Indiana Jones does vary the sample count on terrain overlays such as road tracks, which is where changing the level was most noticeable due to these overlays often running at max sample count and on a large screen area.
The code ported straight over from Indiana Jones to DOOM: The Dark Ages and shipped in that title also with only a minor tweak to parameters. Both games shipped with a perf or quality win depending on scene load, and nobody noticed or complained (that I noticed). Indiana Jones won Digital Foundry’s technology of the year 2024 (despite the ‘knocked up in a day’ anisotropic scaling algorithm), huge congrats to everyone involved!
The same algorithm can be used to tie any graphical setting to DRS where a frequent change or flip-flip of state is objectionable, but an infrequent change particularly with a moving camera may go unnoticed. For example, I fully expect the same algorithm could be used for shadow map size or shadow filtering quality. Other parameters can be tied to DRS scale directly without this algorithm, e.g. VRS shading rate, which we did on Doom. (Another shameless plug! See GPC 2025: Variable Rate Compute Shaders in Doom the Dark Ages)
Always great to work with the talented teams at Machine Games and id Software and thank you to both for allowing me to share.
The code below is of course trivial to generalise to other settings, not just anisotropic sampling. The code is modified from as-shipped only to aid portability and understanding.
