The reason many bits were removed from the PC list was that those features have been moved to a LUT outside of the tone mapping shader. We don’t need permutations to optimize these different features being on. This was a large simplification to the tone mapper. The number of permutations shrank dramatically. It also resulted in a healthy optimization. I’d like to eventually do the same with the mobile path but I need to make absolutely sure it is at least as fast as what is there currently.
The only bit that was removed from the mobile list was vignette color which is no longer supported. The feature was removed. It being removed should not affect whether a match is found since it will no longer be looking for that bit.
The fail case should never happen. There should be an entry in the list that has all possible features which it will find a costly match with. Maybe there should be a check() there instead if it doesn’t find anything. The order is done such that the first entry is the expected most common and the last is least common. This will help the exact match case. If there isn’t an exact match the order doesn’t matter.
I do see a bug for the PC path which adds bits in TonemapperGenerateBitmask for features which aren’t in the PC list anymore. I just added code to wipe out those bits in TonemapperGenerateBitmaskPC.