Clear or validate resources to be initialized

[kvark]

The upstream spec requires us to zero-initialize resources: buffers and textures. I'm not a fan of that personally, but we need to validate the initialization regardless. Currently we aren't validating that. Example complaint:

[2020-04-08T16:09:02Z TRACE wgpu_core::command::render] Encoding render pass begin in command buffer (0, 1, Vulkan)
[2020-04-08T16:09:02Z WARN gfx_backend_vulkan]
VALIDATION [UNASSIGNED-CoreValidation-DrawState-InvalidRenderpass (0)] : Render pass has an attachment with loadOp == VK_ATTACHMENT_LOAD_OP_LOAD and initialLayout == VK_IMAGE_LAYOUT_UNDEFINED. This is probably not what you intended. Consider using VK_ATTACHMENT_LOAD_OP_DONT_CARE instead if the image truely is undefined at the start of the render pass.

The desired behavior here is to lazy-initialize resources that the user doesn't properly initialize, and issue a warning otherwise.

[Wumpf]

I might be interested in solving this :)

The desired behavior here is to lazy-initialize resources that the user doesn't properly initialize, and issue a warning otherwise.

So the idea is that the zero initialize is explicitly discouraged and logs a warning? I was actually hoping to rely on in it for a few things - I have some awkward "if this is first frame then read zero instead" things so far since there's no general clearbuffer/texture exposed :/

Besides this sentiment, there's a couple of cases where I'd argue it's too hard to avoid this warning since I believe there is only two ways to transparently clear a texture/buffer:

• fill it entirely on creation
• clear on start of a renderpass

(binding for write doesn't help because shader may not actually write any data)

This is a bit problematic for a wide range of usecases. E.g. a large voxel volume that is to be filled with mesh data at runtime has no way of clearing to zero other than creating a large zero sized array and "uploading" that on creation. This is unfortunate since inside the wgpu implementation we could call clear_image/fill_buffer which are much cheaper & easier but sadly not exposed in WebGPU.

[kvark]

Upstream requires this to be the desired behavior, so if you are interested in implementing it this way, without any warnings, we'd be totally cool, and much appreciated! This is one of the core bits of the API that we haven't progressed with, and it's getting needed more and more.

I have a slight concern about users actually relying on this behavior, which I'll try to explain here, but I'm not going to push it. If somebody relies on the blank state at start, they would eventually want to "reset" a resource to this state, to rely on that again. And then they'll demand clear_image and fill_buffer on the API level (as you mentioned). But if we have those exposed, then users will get all the tools they need to avoid uninitialized resources, so the case needs to be made about why we should be doing this work for them. When reading the code, I'd like to see more explicitly what's going on. An implicit operation that mutates resource contents goes across that.

[Wumpf]

Makes sense but my line of argumentation is that users will need/want clear_image/fill_buffer more so if we issue a warning (so they can avoid it).

I actually thought the doing work for them part is entirely motivated by security guarantees for the web in order to avoid reading out uninitialized memory. That would hold true no matter what is exposed.

[kvark]

Yes, I agree, the warnings are not sound. We need to either silently provide this (like upstream), or make it an error entirely. Both approaches are secure.

[kvark]

The buffer initialization has landed in #1159. The textures can be implemented with clear_image calls internally, but there is also gpuweb/gpuweb#1422 that could be blocking this.

[kvark]

#1102 is left for textures