Optimize depth-testing in the opaque batch lists of WebRender
Categories
(Core :: Graphics: WebRender, task)
Tracking
()
People
(Reporter: kvark, Unassigned)
References
(Blocks 1 open bug)
Details
Problem
WR's opaque batch lists rarely show up as a problem in CPU profiles. However, they may have a hidden performance cost on GPU side: whenever we re-order instances, and they intersect, we are going to have the GPU overwriting pixels. That means: more fragment shader execution, more depth writes and color writes. This is a trade-off, and in case of integrated GPUs we are talking about the shared memory bandwidth. So we'll see it manifesting in, say low-end Intels having a hard time on CPU side for apparently no reason.
The current guards against opaque overwrites are :
- loopback count, which is defaulted to 10. Since each batch can have thousands of instances, this loopback doesn't really represent our threshold clearly
batch_area_threshold, which is set to 25% of the whole size. Notably: it's applied to an instance only, not the whole batch. So if a page ends up with lots of instances, each 24% of the whole size, the threshold would not do anything about them.
The worst case here seems pretty much unlimited in how bad it can be. We can have any instance being totally overwritten, which makes our depth testing useless.
Solution
We need to track the instance/batch rectangles in a similar fashion to how we are doing this for transparent batches. However, instead of having a hard cut on "intersection breaks the batch", we can have a budget of, say, 20% of the instance can be overwritten by later batches.
This should play well with the item rect optimization that @nical is working on.
Description
•