Support for attach-less render passes

[kvark]

There is a use case of doing a render pass with no attachments. For example, when the pixel shader does some work with storage buffers, and we still want rasterization to happen, just without rendering per se.

Currently what happens is - we don't know the rasterization area when the render pass is started, and our implementation panics. It has no way to know this today.

Possible solutions:

1. say this is an unsupported use case. Users could technically have a dummy attachment and set up the blend equations to always fail...
2. have an optional member of RenderPassDescriptor with the rasterization area. When not set, it's automatically derived from the attachments, which are expected to be of the same size.

[kvark]

Pinging @RafaelCintron and @litherum for whether it's even a good idea in Metal to have no targets/attachments in a render pass.

[Kangz]

Looking at the Vulkan spec, this seems to be a supported usecase in vanilla Vulkan (I said the contrary in some other conversation but was wrong)

[kvark]

Moving to V1.0 to quickly mention in a discussion time slot. It may fall under the category of "allowed by all the native APIs", in which case we need to expose it.

[Kangz]

I gave it a try in Dawn https://dawn-review.googlesource.com/c/dawn/+/63140 and even if I wasn't able to get the shader to write to an SSBO, I found interesting data.

On Metal, using attachment-less render passes requires setting the renderTargetWidth, renderTargetHeight and defaultRasterSampleCount members of MTLRenderPassDescriptor. These members were introduced in macO 10.15, so I don't think we can rely on them for WebGPU. This feature should probably be part of a later "flexibility" optional feature that isn't present on all systems.

[Jiawei-Shao]

On Metal, using attachment-less render passes requires setting the renderTargetWidth, renderTargetHeight and defaultRasterSampleCount members of MTLRenderPassDescriptor. These members were introduced in macO 10.15, so I don't think we can rely on them for WebGPU. This feature should probably be part of a later "flexibility" optional feature that isn't present on all systems.

Maybe we can create a dummy color attachment with the given renderTargetWidth, renderTargetHeight and defaultRasterSampleCountinside the browser implementation as a workaround for macOS 10.14 and below?

[Kangz]

That would work, but I don't think it qualifies as "all APIs support it" since we need emulation on Metal, and most likely on D3D12 when using D3D12 render passes. IMHO we should have a later extension for a bunch of nice to use feature that improve flexibility but might require emulation.

[kvark]

Thanks @Kangz ! That is a good argument to postponing this.

[kainino0x]

On Metal, using attachment-less render passes requires setting the renderTargetWidth, renderTargetHeight and defaultRasterSampleCount members of MTLRenderPassDescriptor. These members were introduced in macO 10.15, so I don't think we can rely on them for WebGPU. This feature should probably be part of a later "flexibility" optional feature that isn't present on all systems.

Funny, this is exactly what we found we would need to do in order to support this feature. I suppose Metal must have added those for the same reason.

[magcius]

Now that we mandate support for OS 15+, could we revisit this and see if we can add it?

[kainino0x]

Evidently Chromium is/was already out of spec here, and somehow we accidentally allowed render passes with no attachments:
gpuweb/cts#3808 (and gpuweb/cts#3754, gpuweb/cts#3806, gpuweb/cts#3755)
But I don't know what it actually does, given we then have no way of knowing the render pass size.

It would be really nice if we could lift that restriction!