Currently, WebRender collects each batch instances into a separate Vec. Right before drawing, that data is passed to the gpu via a new "stream"-like vertex buffer. This is concerning for multiple reasons:

• growing a separate heap allocation per batch means a lot of copying of data, and pressure on the heap allocator
• uploading before drawing puts a dependency on the driver/GPU. I suspect this is mostly alleviated by the fact that the drawing is encoded into command buffers that are executed once per frame (or more, but not once per batch).
• creating that many small temporary buffers puts pressure on the drivers to recycle memory efficiently. Android has been known for not liking it with regards to texture updates.
• that's a lot of communication to the driver and potential state invalidation. We'd want to talk to the GL driver as little as possible, since there is an Angle state machine followed by the driver state machine on Windows, and any operation has CPU cost.

This task is about uploading the instance data in larger chunks at once.
This will also potentially evolve into sharing the instance data memory directly between the frame builder and the renderer.

This will be blocked on the Angle update, and we can land it gradually.

In the short term, this would result in less heap allocations on frame building.
For example, we no longer have a Vec<InstanceRect> per batch, stored in a separate Vec,
and we don't have a separate Vec<InstanceData> per batch.
There is also a matter of code refactor and cleanup that could make our life better.

In the longer term, once Angle is updated, we'll be able to lift the VBO updates up
accordingly, and use baseInstance drawing with them.

Sub-commits:

• Minor refactor of the batch intersection logic
• Instance stacks for transparent alpha batches
• Use instance stacks for opaque batches as well
• Implement and re-enable batch list merging
• Encapsulate instance stack LRU indexing into a class
• Internal BatchList type, bumped StackIndex size.
• Adjust the tests
• Test the stack count of 4

Backed out for perma failures on 456219-1a.html.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=DF9OFOPrSaCG0KCyMvNJ4g.0&resultStatus=success%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception&searchStr=windows%2C10%2Cx64%2Cwebrender%2Cdebug%2Creftests%2Ctest-windows10-64-qr%2Fdebug-reftest-e10s-1%2Cr%28r1%29&revision=88406054eb6c146cf607429a09a8f3814bbbb5e5

Logs: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=306010414&repo=autoland&lineNumber=20091
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=306023962&repo=autoland&lineNumber=32994

Backout: https://hg.mozilla.org/integration/autoland/rev/29972ad4261517555b4e74990f402426136a357e

I'm going to rework this in a different way.

The leave-open keyword is there and there is no activity for 6 months.
:kvark, maybe it's time to close this bug?

It's still needed

When instancing is disabled, this path tries to consolidate instance data into large
vertex buffers, and draw parts of it separately.

The leave-open keyword is there and there is no activity for 6 months.
:kvark, maybe it's time to close this bug?

I think Jamie's work will get this working as originally desired. Jamie, do we need to keep this open, or you have other bugs filed for this?

It sounds like this in includes packing instance data in to larger vecs during batching, whereas my patch only packs them in to larger VBOs while rendering. So this would still be a worthwhile improvement, as it could reduce the number of maps/buffer uploads we perform, as well as require fewer heap allocations

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:kvark, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

I'm guessing we'll need to abandon this one for now, but maybe we'll be able to revisit this patch as a reference in future?

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.