-
Notifications
You must be signed in to change notification settings - Fork 353
Add per-pixel accounting of render target depths #3367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.