-
Notifications
You must be signed in to change notification settings - Fork 335
Add description of sample footprint #4683
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
Previews, as seen when this build job started (6df6b39): |
I honestly never fully understood the sample footprint thing. The term was copied from Metal docs: I think it's this complicated idea of like, project the fragment footprint onto the surface (as determined by some derivatives), that gives you some quadrilateral, if the area if that quadrilateral is >1 texel in area, it's minification, if it's ≤1 texel, it's magnification. Or it's just a high level intuitive description of how it works and we shouldn't try to formalize the language as it stands. If we really want to formalize it we can try to adopt structure from Vulkan:
Though honestly I don't think it's worthwhile trying to get too deep into it - we were saying in yesterday's WG meeting, if an implementer (over a native API like Vulkan) wouldn't face any ambiguity over what to do, it's fine if we're not so rigorous. If we do want to be rigorous, I think it would be best to delegate out to the Vulkan spec. This would be a simpler one to delegate than the rendering algorithm. |
Updated this based on the example set in #4694. (Which, conveniently, is the paragraph above this one.) Now includes a non-normative reference to the relevant section of the Vulkan spec. Please take another look! |
spec/index.bs
Outdated
The <dfn dfn>sample footprint</dfn> of a sampler describes the texels accessed by the sampler for a | ||
given [=texture coordinate=]. Depending on the {{GPUFilterMode}} this may be up to four texels of a | ||
given mip level, and depending on {{GPUMipmapFilterMode}} may include samples from multiple mip | ||
levels. |
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.
The way "sample footprint" is used earlier (where it could be smaller than one texel) implies that it's some arbitrary quadrilateral covering some arbitrary (fractional) area of a 2d UV space. The wording came from Metal but Vulkan supports this wording too:
If ρmax = ρmin = 0... the fragment’s footprint in texel space is a point, and η should be treated as 1.
If ρmax ≠ 0 and ρmin = 0... the fragment’s footprint in texel space is a line segment
(couldn't find a case where they describe it as a quadrilateral but that seems to be the implication)
A point sampled in screen space has an elliptical footprint in texture space.
(I have no idea why it's elliptical since vulkan doesn't have "smooth points", would expect a quadrilateral)
This text here it implies it's either 1 texel or 4 texels (per level). Also, I think we should try to say less.
Here's an idea of what we could write if we want to say a lot here:
A <dfn dfn>sample footprint</dfn> describes the texture-coordinate-space sub-region
corresponding to the source of a texture sample operation.
The footprint and the set of texels used to compute the actual sample result depends
on the texture size, mip-level count, sampler parameters, and WGSL sample call arguments.
However... what if we just removed all references to "sample footprint" and described what filter/address modes do in higher-level/intuitive terms instead?
(keeping the Vulkan pointer for real details)
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.
Took a stab at removing the sample footprint definition entirely. Let me know what you think!
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 think this is good.
Fixes #2343.
This is a pretty high-level description, but it's not clear to me that we want to make it too much more detailed (at which point it would probably belong in the Detailed Operations section/doc). Happy to expand on it if needed, though.