Should textures be cleared

[Rik Cabanier]

The spec doesn't call out that opaque textures should be cleared by the author prior to their use.

We recently updated our code so opaque textures follow the spec language but are now wondering if that is the correct behavior.
According to @Artyom17, this might be tricky because a texture needs to be bound for it to clear.

[Rik Cabanier]

/agenda should we update the spec so texture are always cleared when calling getSubImage/getViewSubImage

[Artem Bolgar]

So, the issue is that there is no obvious moment of time when the textures could be cleared or even invalidated. The current frame flow is as follows:

BEGINNING OF AF

<some code>
for each view:
   layerInfo = getViewSubImage
   gl.framebufferTexture2D(COLOR_ATTACHMENT, layerInfo.colorTexture)

   <some code>

   render
END OF FRAME

Note, the layer's color textures got detached from FBO after the frame is finished.

Thus, the question is: where exactly the clear should occur (if at all)? We can't clear it till the texture is attached to an FBO, but do we change the behavior of framebufferTexture2D?
Another option is to mark the texture as 'discarded' (but we can't discard it for real till the frame begins). In this case the clear should occur at the first attempt of rendering (at least in Chromium). But it is also kinda couter-intuitive since even the clear color could be unpredictable at that time (for example if the clearColor was changed somewhere between the framebufferTexture2D and "render"). Any thoughts?

[Rik Cabanier]

@jdashg what do you think?

[Kelsey Gilbert]

Spec that the textures returned by getViewSubImage are cleared/uninitialized (like other uninitialized webgl resources), which allows the implementations to do lazy clearing on draw, as we already do for all other webgl resources.

Don't worry about clearColor, as our implementations already handle this for textures, ensuring that textures are cleared to proper zero values regardless of the userland clearColor state.

[Artem Bolgar]

@jdashg when EXACTLY do you clear / uninit the texture? At the first rendering attempt (i.e. the same as what happens when invalidateFramebuffer is called)?

[Kelsey Gilbert]

Yes: It's an implementation detail, but generally just-in-time before the first draw to the resource. It's analogous architecturally to VK_ATTACHMENT_LOAD_OP_CLEAR.

[Artem Bolgar]

got it

[Rik Cabanier]

It seems we are all in agreement that textures should be cleared. I'll close this issue.