Hello,
I am looking at this, but I’m not 100% sure what the problem is you want to have fixed. For the on screen timer and the scheduling percentage:
The first number 195.3 means it is updating 195.3 times per second, which means 1000 / 195.3 ~ 5.1ms /frame… this number aligns with the numbers you see on CPU and GPU. The second number is how long the render job took CPU time wise, in this case 0.7ms. The last number is a percentage of the render job time / total frame time. Or in this case 0.7 / 5.1 ~ 13%.
What this means though is that the render job is 5.1 - 0.7 = 4.4ms idle, doing nothing (or ~87%). With optimizations we have done over the last years we use some of that idle time to try to improve the situation. Things like occlusion culling try to not render objects that cannot possibly be seen, as that could help improve the overall frame time, if we’re GPU bound. In your screenshot the GPU also took 5.1 ms, so that means we’re pretty much GPU bound… while at the same time the CPU is idle 4.4ms (for rendering that is).
So the goal of the optimizations is to use some of the idle time to see if we can reduce the workload on the GPU. However doing so increases the render job time… and as such the last number in the “Schedule render”. For example… say we spent 1 ms to do occlusion culling… then the renderjob time would be 1.7 ms, which would end up being 1.7/5.1 ~ 33%. However this has another side effect… usually the GPU now renders less, because we send it less commands. So since the frame was previously GPU bound, imagine that we now saves 0.5ms off the GPU time. This would make the GPU time 5.1 - 0.5 = 4.6. (And consequently the FPS ~217.4). However that further drives up the percentage… since now it is not 1.7/5.1 ~ 33%, but 1.7/4.6 ~37%.
Or for the microprofile you have attached:
Here it is clear that YES we are spending CPU time, and that time increases the "Schedule Render % in the on screen display, but that CPU time doesn’t negatively affect frame rate. It most likely helps the framerate to get better since we’re GPU bound and that CPU time is spent to send less to the GPU.
So in essence this is not a bug, this is an optimization to improve framerate overall. Have more time in the render job 80% - 90% provided that it benefits FPS (sometimes it doesn’t because if a scene is nearly empty, or you look at an empty part, there’s not much optimization you can do with things like occlusion culling).
That leads sort of to you next part where sometimes pieces behind a wall go hidden and sometimes they don’t. We have heuristics to determine if running occlusion culling helps. As soon as we approach the place where doing the occlusion costs more time than it would save, we don’t do it. There are a lot of other heuristics around this, due to how the occlusion culling works. This makes it not easy to understand from an outside point of view on the decisions it makes.
If you want a slightly better understanding of how it works you can look at https://advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf. The basics of the technique are the same, but we have a lot of custom heuristics that help decide.
One thing you can see in your example, since this feels counter intuitive is that the tech occludes more objects when looking straight onto the first wall as opposed to at an angle.
This has to do with how occlusion culling works against a hierarchical depth buffer. Slide 26 of the previously mentioned slide deck gives some intuition as to why this is… when looking straight onto the first wall, the conservative depth in the depth pyramid has fairly equal conservative min depth across the entire surface. When the angle gets more slanted, the conservative min depth is correct for the high detail occlusion depth, but due to the nature of creating the hierarchy the conservative min depth basically becomes the furthest away point. of that wall. As such all other wall segments have pieces that are closer than the conservative depth at the area of the pyramid where we only need to test 1 sample… and therefore we cannot early reject it.
Another example of why it unintuitive to figure out what occlusion object we take has to do with selecting the best occluders.
Anyways, all this is to say that… I wouldn’t try to reason about what are good occluders vs not. We have spent a long time tuning this number against virtually millions of experiences and there is lots of tech behind it that shows that on average it increases frame rates on most titles. There have been edge cases where occlusion culling was occasionally detrimental and we’ve spent a lot of time refining that and automatically turning it off when it isn’t helpful.
If you believe however that it is not helping your title, please create a place file with a fixed camera, with the exact same angle, scenario, etc. So that we can run a test with optimizations on and off. And then we can tweak the algorithm further if needed.
