1602550 - Belt texture data uploader for WebRender

Status: NEW

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

Description

[Dzmitry Malyshau [:kvark]]

Solution to bug 1598380 now allocates one big PBO per upload "session" and requires the clients (of TextureUploader) to have an extra pass over the uploads to get a size estimate.

I believe we can improve it by having a general purpose uploading machinery, the "belt":

• it would manage the PBOs internally (instead of accepting as a parameter)
• the client requests an upload, and the "belt" checks how many rows it can fit into a currently mapped buffer
• if needed, it creates a new PBO on the spot, maps it, and continues writing the updates there
• in this case all the copy commands for the previously open PBO can be dispatched, and the PBO can return to a pool to be re-cycled.
• at some point, it is given a "flush" command to close the currently open PBO

What are the benefits comparing to the current state:

1. hides the PBO concept completely
2. doesn't require 2 passes
3. allocates the data in regular chunks (not considering the outliers)

Comment 1

[Jamie Nicol [:jnicol]]

Yes, sounds very similar to what I had in mind for the future :)

if needed, it creates a new PBO on the spot, maps it, and continues writing the updates there

We should even just be able to call glBufferData and rely on the driver internally allocating a new PBO. Then we don't need to do any recycling or synchronisation ourselves. Obviously we'll need to ensure drivers can do this reliably.

Need to pick a sensible fixed buffer size. Then think about what we do if an upload exceeds that's size (split in to chunks, or allocate a larger buffer)

Comment 2

[Markus Stange [:mstange]]

(In reply to Jamie Nicol [:jnicol] from comment #1)

Yes, sounds very similar to what I had in mind for the future :)

if needed, it creates a new PBO on the spot, maps it, and continues writing the updates there

We should even just be able to call glBufferData and rely on the driver internally allocating a new PBO. Then we don't need to do any recycling or synchronisation ourselves. Obviously we'll need to ensure drivers can do this reliably.

But glBufferData will always do a copy. If we map the buffer and do the copy ourselves, then we can work on eliminating the copy in a future step, by having the RenderBackend write its data directly to the mapped location, see bug 1604546.

Comment 3

[Jamie Nicol [:jnicol]]

I should have said glBufferData and passing null as the data parameter, which shouldn't do any copy. Then map and copy ourselves.

Perhaps glBufferStorage could be useful too, though I haven't looked much in to it.

Comment 4

[Markus Stange [:mstange]]

Oh, I see.