Add the definition of renderable format #1653
Conversation
It defines renderable format, and color renderable format, and depth or stencil renderable format as well. It removes one issue that rgb9e5unorm cannot be used as a color attachment because rgb9e5unorm is not color renderable. Any format has a -snorm suffix or any compressed format cannot used as a color attachment because all of them are not color renderable. We have already added this validation rule in `GPURenderPassColorAttachment Valid Usage`. We don't need to have separate text in the spec for rgb9e5unorm particularly. renderable format definition is also needed for texture creation. If a format is not a renderable format, it will fail with its sampleCount > 1, or when its usage include `RENDER_ATTACHMENT`. The later validation rule also make rgb9e5unorm + color attachment combination fail.
Co-authored-by: Kai Ninomiya <[email protected]>
spec/index.bs
Outdated
| or <dfn>depth or stencil renderable format</dfn>. | ||
| - If a format is listed in [[#plain-color-formats]] with {{GPUTextureUsage/RENDER_ATTACHMENT}} | ||
| capability, it is a color renderable format. Any other format is not a color renderable format. | ||
| - Any depth/stencil format is a depth or stencil renderable format. Any other format is not |
There was a problem hiding this comment.
do we need this definition? wouldn't it be simpler to just say "it has to be a depth of stencil format", referring to the table, instead of saying "it has to be [=depth or stencil renderable format=]"? the extra indirection here may be confusing.
There was a problem hiding this comment.
Note that I am defining 3 things. The purpose is to define renderable format, which is useful for texture creation validation (see the comment of this PR). color renderable format and depth or stencil renderable format are sort of the by-products, but they are also useful for a couple of places in the spec (but without definition), so I updated these places and directed to the definitions here.
There was a problem hiding this comment.
It sounds to me that you really want to define renderable format and color renderable format, but the depth-stencil renderable is still redundant?
There was a problem hiding this comment.
BTW, I will add <dfn>, </dfn> stuff for renderable format in the next PR for texture creation validation.
There was a problem hiding this comment.
ok, if that's simpler for you.
…puweb#1653) The queryType of each timestampWrite in timestampWrites should be `timestamp`. So, this PR adds a test to check if a validation error is generated if all query set types aren't `timestamp`. Issue: gpuweb#1618
3 participants
It defines renderable format, and color renderable format, and
depth or stencil renderable format as well.
It removes one issue that rgb9e5unorm cannot be used as a color
attachment because rgb9e5unorm is not color renderable. Any
format has a -snorm suffix or any compressed format cannot used
as a color attachment because all of them are not color
renderable. We have already added this validation rule in
GPURenderPassColorAttachment Valid Usage. We don't need tohave separate text in the spec for rgb9e5unorm particularly.
renderable format definition is also needed for texture creation.
If a format is not a renderable format, it will fail with its
sampleCount > 1, or when its usage include
RENDER_ATTACHMENT.The later validation rule also make rgb9e5unorm + color attachment
combination fail.
Preview | Diff