Open Bug 1640952 Opened 4 years ago Updated 3 years ago

Share staging data between the frame builder and the renderer

Categories

(Core :: Graphics: WebRender, enhancement)

enhancement

Tracking

()

People

(Reporter: kvark, Unassigned)

References

(Depends on 1 open bug)

Details

This would play well with the staging belt of bug 1602550 as well as the instance data consolidation in bug 1636645, but is not a requirement to get them.

We need to encapsulate the machinery of managing the staging space used for texture and buffer data update. This encapsulation should have the following API, roughly:

trait StagingMachine {
  /// Allocates a new staging slice of size `size` and returns it
  /// together with the location of the segment in some PBO buffer.
  ///
  /// Note: the location information is valid up until `reset` is called.
  ///
  /// Note: can be called from either the frame builder or the renderer,
  /// but before the `close()` call or any GL operations.
  fn stage(&mut self, size: usize) -> (&mut [u8], PBOId, BufferOffset);
  /// Closes all the mapped buffers, at which point it's valid to start issuing
  /// OpenGL commands that use the returned PBO IDs.
  fn close(&mut self);
}

The key difference with bug 1602550 is the ability to stage data from the render backend. Instead of collecting texture updates, for example, it can write them down instantly. When a slice is requested, it first would create a new PBO of some fixed size, and map it right away. By the time the renderer starts, all the data is ready for GPU operations, and everything can be unmapped by close().

The trick here is that all PBO creation and mapping has to happen on the renderer side. So this can be implemented as a synchronous message passed to Renderer and received back, with a blocking wait. However, once a buffer is mapped, a pointer to the mapping can be shared to the frame builder. There is a concern about the situation where the renderer is busy, and the frame builder becomes blocked by it, unable to upload any data.

Note that it works without persistent mapping (introduced in EXT_buffer_storage), we are just not going to use the same staging PBO across different frames.

Once this machine is set up, we can use it for texture uploads as well as to host the instance data. The main goals to achieve is reducing the data copying and object allocation within GL driver.

Depends on: 1602550
You need to log in before you can comment on or make changes to this bug.