Add per-pixel accounting of render target depths#3367
Conversation
9c55821 to
c6701da
Compare
|
Previews, as seen when this build job started (c6701da): |
c6701da to
6a57a2f
Compare
|
Previews, as seen when this build job started (6a57a2f): |
kainino0x
left a comment
There was a problem hiding this comment.
lgtm % nits and bikeshedding
spec/index.bs
Outdated
| {{GPURenderPassDescriptor}}.{{GPURenderPassDescriptor/colorAttachments}}, | ||
| and {{GPURenderPassLayout}}.{{GPURenderPassLayout/colorFormats}}. | ||
|
|
||
| <tr><td><dfn>maxTotalColorAttachmentDepth</dfn> |
There was a problem hiding this comment.
"Depth" is slightly confusing here because we aren't able to say the less ambiguous "bit depth".
I might call this... maxColorAttachmentBytesPerFragment? PerSample?
There was a problem hiding this comment.
well, it's not per fragment, and it's not per sample. I think the term-of-art for this is, surprisingly, per pixel. maxColorAttachmentBytesPerPixel it is.
| <tr><td><dfn>maxTotalColorAttachmentDepth</dfn> | ||
| <td>{{GPUSize32}} <td>[=limit class/maximum=] <td>32 | ||
| <tr class=row-continuation><td colspan=4> | ||
| The maximum number of bytes necessary to hold a pixel, across all color attachments. |
There was a problem hiding this comment.
I'd use "fragment" or "sample" instead of "pixel" so the meaning is clearer in the multisampled case.
There was a problem hiding this comment.
Right, as above, I think "pixel" is actually the term-of-art to refer to "the thing that includes all samples in all relevant texels of the render targets."
Our docs call this "Maximum total render target size, per pixel, ..."
There was a problem hiding this comment.
Hmm. The accounting algorithm doesn't multiply by the sampleCount or anything like that though. Isn't this effectively the size of all of the data coming out of the fragment shader (, blending, etc.)?
|
Previews, as seen when this build job started (0018dda): |
|
Removing 'needs-cts-label' after filing draft issues:
|
maxColorAttachmentBytesPerSample
Fixes #2965.