Belt texture data uploader for WebRender
Categories
(Core :: Graphics: WebRender, task, P3)
Tracking
()
People
(Reporter: kvark, Unassigned)
References
(Blocks 2 open bugs)
Details
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:
- hides the PBO concept completely
- doesn't require 2 passes
- allocates the data in regular chunks (not considering the outliers)
Comment 1•5 years ago
|
||
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)
Updated•5 years ago
|
Comment 2•5 years ago
|
||
(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•5 years ago
|
||
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•5 years ago
|
||
Oh, I see.
Updated•2 years ago
|
Description
•