Closed Bug 1564293 Opened 2 years ago Closed 2 years ago

Track 3D/2D_ARRAY texture data invalidation by-slice


(Core :: Canvas: WebGL, enhancement, P2)




Tracking Status
firefox70 --- fixed


(Reporter: jgilbert, Assigned: greyson.gilbert.oss)



(1 file)

Currently, if you create (e.g.) a 2D_ARRAY texture and populate it slice-by-slice, you get this warning when populating (clear, (copy)texSubImage, blitFramebuffer) the first slice:

Error: WebGL warning: texSubImage3D: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.

Now, when we resolve a texture as complete for drawing, we'll need to ensure that all slices either have been populated, or clear them ourselves. However, we should expect well-behaved apps to have populated all the slices, and if they don't we should definitely issue a warning.

The max-sizes here are medium sized, about 2k-4k.

2kbits is 250bytes, so it wouldn't be so bad to store a bit-vector of some type.

Before this patch any partial upload to a texture would incur
a zeroing of the texture first to prevent leakage of information.
The texture now tracks, for each image not fully initialized,
which z-slices have been initialized, and only zeroes the rest
of the slices when the texture is used.

I haven't done any perf testing or big optimizations, but I wanted to make sure that the general layout of the changes is acceptable.

Pushed by
Allow efficient slicewise upload of 3D textures r=jgilbert
Assignee: nobody → greyson.gilbert.oss
Flags: needinfo?(jgilbert)

Well, I'm not a fan of that being a -Werror, but I suppose it does make the copy clear. (Though in this case, I would generally prefer const auto& to say "whatever's most efficient")

Pushed by
Allow efficient slicewise upload of 3D textures r=jgilbert
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.