Setting up a texture without uploading initial data

[philippotto]

Is your feature request related to a problem? Please describe.

The problem is mainly related to the performance cost of setting up a big texture which is populated incrementally. Allow me to give some context:

I'm using a custom texture subclass which exposes texSubImage2D for that particular texture. The class is inspired by this code, but is adapted to WebGL 2. You can find the custom subclass here.

In my use case the updatable texture (typically sized 8192²) is populated in chunks which is why I'm using texSubImage2D. This means that the initial texture data is empty. However, with the current approach, I need to allocate a data buffer (e.g., with length == 8192²) so that the texture can be initialized with this data. This is suboptimal from a performance perspective since

1. I need to allocate the data buffer (depending on dtype this can be well over 200 MB) even though I don't need this buffer for the partial updates and
2. threejs uploads the data to the GPU even though it's not really necessary (as it's only zeros). The initial upload roughly takes 1 second for my data load which I'd like to avoid.

For WebGL 1, one could make the texture size 1x1 initially and resize it before the first usage. However, in WebGL 2 this is apparently not possible anymore, since the texture size is immutable.

I found a workaround to the performance problem by passing { width: actualWidth, height: actualHeight, data: new Uint32Array(1) } to the constructor super call of the Texture class. This avoids the unnecessary memory allocation and texture upload. However, it obviously leads to a WebGL error, since the upload call texSubImage2D fails due to the incorrectly sized data array. The rendering works fine afterwards, but the failing WebGL call + error message in the console is not really satisfying to me.

Describe the solution you'd like

I think, it would be ideal if we could tell ThreeJS somehow that it shouldn't do the initial data upload with texSubImage2D or texImage2D in uploadTexture. The rest of the function (i.e., the whole texture setup) should still happen. For example, texture.image.suppressInitialTextureUpload = true could be set on the texture to skip the upload call.

Describe alternatives you've considered

• Handling the texture setup without threejs would also be a viable option to me, but I still want to attach the texture to a ThreeJS material so I'm not sure how this could work.
• Texture SubImage Interface #17162 could also be of interest, but 1) there's little progress on this regard 2) the lazy initialization wasn't yet discussed there.

[Mugen87]

However, in WebGL 2 this is apparently not possible anymore, since the texture size is immutable.

Correct, because we use texStorage2D() now, see #21874 and related PRs.

I'm not sure about this feature request. In three.js we do in general not support "half-done" textures. A initial texture object has an internal version of 0 because needsUpdate has never been set to true. As soon as you do that, you tell the engine the texture has been fully loaded and is ready for upload and usage. The engine performs now the combination of the memory allocation via texStorage2D() and the initial data upload via texSubImage2D(). Subsequent updates only trigger the texSubImage2D() because the memory for the texture has already been allocated.

The suggested suppressInitialTextureUpload property would bypass the initial call of texSubImage2D(). However, I'm not sure the specific state of the texture at that point is something we want to support in three.js. IMO, it would mean something like "the memory for the texture is allocated but the data are still incomplete so it is no ready for rendering". Why would you use/render such a type of texture? I would expected to have default data in any event which are possibly later replaced via texSubImage2D().

[philippotto]

Thank you for your reply!

In three.js we do in general not support "half-done" textures.

However, I'm not sure the specific state of the texture at that point is something we want to support in three.js. IMO, it would mean something like "the memory for the texture is allocated but the data are still incomplete so it is no ready for rendering".

I would expected to have default data in any event which are possibly later replaced via texSubImage2D().

I understand this stance, but would like to clarify that a texture is not "half-done" but instead simply null-initialized after using texStorage2D (at least, if I understand the spec correctly). For me, this is analoguous to an allocation of a data array à la new Uint32Array(10) which is also usable and "done" after allocating without passing some initial data explicitly.

Why would you use/render such a type of texture?

In my case a completely zeroed texture is perfectly valid and usable (the application I'm developing renders data that is streamed in a chunked manner; if no data is available the data texture is empty and the shader can deal with that). As soon as the first data chunks arrive from the server, the texture is populated incrementally and the first chunks can be rendered as soon as possible. Note that due to the chunked loading + texSubImage2D, there is never a need to have a huge buffer that mirrors the texture data 1:1.

---

To frame the issue a bit differently: There is currently no elegant way to zero-initialize textures efficiently in ThreeJS. Even though, texSubImage2D does this automatically, one has to allocate a big zeroed buffer to upload that.

For example, texture.image.suppressInitialTextureUpload = true could be set on the texture to skip the upload call.

Alternatively, one could also think about a placeholder object. Something like THREE.EmptyTextureImage(width, height) which could be passed as the image property for a texture.

I'm not 100% satisfied with my interface suggestions yet, but iterating on a solution probably makes only sense if you agree that the feature should be added at all :)

[philippotto]

Happy new year! I just wanted to share how we solved this problem internally and how ThreeJS could incorporate this in a simple manner.

At the moment, we went with monkey-patching (:see_no_evil:) texSubImage2D, so that it does a no-op if an array buffer of length 0 is passed. Then, we can initialize the image object with something like { width, height, data: new Uint32Array(0) } and the initial texture upload is skipped essentially (thus, avoiding the webgl errors).

ThreeJS could do the image.data.length === 0 check in uploadTexture and skip the texSubImage2D call in that case, since the call would fail anyway (unless the texture size is actually 0, but a) that doesn't really make sense and b) this could be checked for, too). The semantics of an empty initial array would then be, that the texture is updated/populated later in another manner.

If you are interested, I could open a PR for this to make my suggestion clearer and to make the discussion easier.