Closed Bug 1564293 Opened 4 months ago Closed 4 months ago

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

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

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

Details

Attachments

(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.
https://webglstats.com/webgl2/parameter/MAX_3D_TEXTURE_SIZE
https://webglstats.com/webgl2/parameter/MAX_ARRAY_TEXTURE_LAYERS

https://opengles.gpuinfo.org/displaycapability.php?name=GL_MAX_3D_TEXTURE_SIZE&esversion=3
https://opengles.gpuinfo.org/displaycapability.php?name=GL_MAX_ARRAY_TEXTURE_LAYERS&esversion=3

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 jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ac0666e2b27c
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 jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6019fc32fbf3
Allow efficient slicewise upload of 3D textures r=jgilbert
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.