Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

toji
Copy link
Member

@toji toji commented May 29, 2024

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.

@toji toji requested review from kainino0x and jimblandy May 29, 2024 21:12
Copy link
Contributor

github-actions bot commented May 29, 2024

Previews, as seen when this build job started (6df6b39):
WebGPU webgpu.idl | Explainer | Correspondence Reference
WGSL grammar.js | wgsl.lalr.txt

@kainino0x
Copy link
Contributor

I honestly never fully understood the sample footprint thing. The term was copied from Metal docs:
https://developer.apple.com/documentation/metal/mtlsamplerdescriptor
#805

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:
https://registry.khronos.org/vulkan/specs/1.3/html/chap16.html#textures-texel-filtering

If λ is less than or equal to zero, the texture is said to be magnified, and the filter mode within a mip level is selected by the magFilter in the sampler. If λ is greater than zero, the texture is said to be minified, and the filter mode within a mip level is selected by the minFilter in the sampler.

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.

@toji toji force-pushed the sample-footprint branch from bee7bf8 to a2943b7 Compare July 1, 2024 21:19
@toji
Copy link
Member Author

toji commented Jul 1, 2024

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
Comment on lines 5232 to 5235
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.
Copy link
Contributor

@kainino0x kainino0x Jul 1, 2024

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)

Copy link
Member Author

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!

@toji toji force-pushed the sample-footprint branch from a685ce2 to 6df6b39 Compare July 2, 2024 19:01
Copy link
Contributor

@kainino0x kainino0x left a 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.

@toji toji merged commit 1c712f7 into main Jul 3, 2024
@toji toji deleted the sample-footprint branch July 3, 2024 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

describe the "sample footprint"
2 participants