Open Bug 1611145 Opened 4 years ago Updated 29 days ago

Remove (most of) the primitive segmentation

Categories

(Core :: Graphics: WebRender, task, P3)

task

Tracking

()

People

(Reporter: nical, Unassigned)

References

(Blocks 2 open bugs)

Details

Having a vector of segments per primitive adds an indirection that causes many cache misses in various phases of frame building and a lot of hard-to-recycle small vector allocations.

Instead of letting primitives have segments, I propose emitting more pre-split primitives during scene building. For example with nine-patches, emit up to nine image primitives with their own parameters.

Some primitives may emit a large number of segments, for example tiled images when they are decomposed on the CPU. When the number of segments is high it is expensive to decompose them during scene building where we can't take advantage of visibility information. For these we would have an external array of sub-primitives emitted during frame building. the tiled image primitive would keep a range of indices into a dynamic image tiles array kept at the primitive store level, and we would need to handle the indirection during batching only in this specific case.

For the majority of segmented primitives where we know up front that we will have a small number of 10 segments, just generate several infividual primitives.

My motivations behind this are simpler code, more efficient code during frame building, as well as less hacks in the brush shaders.

Sharing data

Currently segments share some primitive-level data. This is both a good and a bad thing. For example the nine-patch code in the shader would need per-segment stretch size, which it doesn't have. Instead it has to take some flags and run complicated logic to reconstruct each segment's stretch size. It would be better if the stretch size was computed once for each segment during scene building.
We don't need to lose the ability to share data between instances, though. Instead of having a primitive index and a segment index we could have a primitive data index and a shared data index. It's trivial to detect during frame building that the previous primitive requests the same shared data and use the same handle. In many cases, though I think that we would be better off simply sharing a little less gpu data.

Blocks: 1782834
Severity: normal → S3
Blocks: wr-todos
No longer blocks: gfx-complexity
You need to log in before you can comment on or make changes to this bug.