Default PostProcessTonemap configuration
Within PostProcessTonemap.cpp, there exists both a TonemapperConfBitmaskPC array and a TonemapperConfBitmaskMobile array. The comment at the top says...
At the end of TonemapperFindLeastExpensive, if it fails to find a matching configuration then it return the first entry and has the following comment...
TonemapperConfBitmaskMobile actually has the gamma only shader as the first, with increasingly more complex shaders after.
TonemapperConfBitmaskPC is the exact opposite with the most complex first. So the gamma comment appears to be contradictory.
I mention all this because after upgrading to 4.8 I'm having to go through PostProcessTonemap and figure out why I am having a bunch of issues and the contradictory comments are not helping. Can this be fixed? Which is the correct pattern?
I believe I did discover that the reduced list of configurations in TonemapperConfBitmaskPC had resulted in some of my shaders now being compiled with the first (most complex) shader. Why was this list reduced?
asked Jul 28 '15 at 11:57 PM in Bug Reports
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.
answered Aug 03 '15 at 06:47 PM
The comments are confusing - seems the code has changes and the comments haven't been updated. It would be nice to have PC and mobile doing it the same order. You clearly identified some issues there. Generally this code is meant to pick the fastest possible shader permutation - the most complex shader should cover all the other cases.
I created "UE-19535 Tonemapper shader permutation code/comment are confusing and behaves wrong in corner cases" to track the issue and get it resolved.
answered Aug 03 '15 at 05:40 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here