GPUSamplerDescriptor and GPUSampler creation spec #805
Conversation
spec/index.bs
Outdated
| <dl dfn-type="enum-value" dfn-for=GPUAddressMode> | ||
| : <dfn>"clamp-to-edge"</dfn> | ||
| :: | ||
| Texture coordinates are clampled between 0.0 and 1.0, inclusive. |
There was a problem hiding this comment.
These will likely need a ton of expanding once we get to specifying how graphics operations work but look like a good initial description.
There was a problem hiding this comment.
Oh yes, this isn't exactly correct (see the comment on GPUAddressMode)
spec/index.bs
Outdated
| to multiple texels. | ||
| - {{GPUSamplerDescriptor/mipmapFilter}} specifies behavior for sampling between two mipmap levels. | ||
| - {{GPUSamplerDescriptor/lodMinClamp}} and {{GPUSamplerDescriptor/lodMaxClamp}} specify the minimum and | ||
| maximum levels of detail, respecitively, when sampling a texture. |
There was a problem hiding this comment.
this may need to be clarified, as "maximum levels of detail used by internally when sampling a texture in the shader". The "internal" bit is important, to avoid confusion with user-provided LOD level in some of the sampling functions.
spec/index.bs
Outdated
| - If {{GPUSamplerDescriptor/compare}} is provided, the sampler will be a comparison sampler with the specified | ||
| {{GPUCompareFunction}}. | ||
|
|
||
| {{GPUAddressMode}} describes the behavior of the sampler if provided texture coordinates are beyond |
There was a problem hiding this comment.
This isn't true, strictly speaking. It affects the filtering on bounds as well, so the texture coordinate can be well within the texture, but the filtering footprint may not.
I think we'll need to specify what the "filtering footprint" is, to explain the filtering. It's fine to do in follow-ups, if we have an Issue here.
spec/index.bs
Outdated
| <dl dfn-type="enum-value" dfn-for=GPUAddressMode> | ||
| : <dfn>"clamp-to-edge"</dfn> | ||
| :: | ||
| Texture coordinates are clampled between 0.0 and 1.0, inclusive. |
There was a problem hiding this comment.
Oh yes, this isn't exactly correct (see the comment on GPUAddressMode)
spec/index.bs
Outdated
| : <dfn>"mirror-repeat"</dfn> | ||
| :: | ||
| Texture coordinates between -1.0 and 1.0, inclusive, are mirrored across the axis. | ||
| Outside -1.0 and 1.0, the texture coordinates wrap to the other side of the texture. |
There was a problem hiding this comment.
I don't think this is correct. What about, say, coordinate -2.5 ? We need to say something like: the texture is mirror expanded to -1.0 to 1.0 range, and that one is expanded. For example, this is how D3D12 describes it:
Flip the texture at every (u,v) integer junction.
For u values between 0 and 1, for example, the texture is addressed normally; between 1 and 2, the texture is flipped (mirrored); between 2 and 3, the texture is normal again; and so on.
|
For some reason, I'm not able to reply to the individual comments on this page right now, but I should have addressed concerns; let me know what y'all think. |
spec/index.bs
Outdated
|
|
||
| {{GPUFilterMode}} describes the behavior of the sampler if the provided texture coordinates do not | ||
| correspond to a single texel. | ||
| {{GPUFilterMode}} describes the behavior of the sampler if the sample footprint is smaller or larger |
There was a problem hiding this comment.
that's not correct. The footprint can be exactly one texel (note: please use "texel" consistently), and we still need to filter it.
What we should be saying here is that "sample footprint does not exactly match a texel". This sounds similar to the previous statements, but there is a critical hidden difference: we are talking about the shape of the footprint here, where other places only talk about the area of the footprint. I think we need to change the other places to say "footprint area" when comparing to 1 everywhere, for clarity.
There was a problem hiding this comment.
Hmm, I thought I replaced all mentions of "pixel" with "texel"; ok
|
uh oh. I think i messed up my branch |
|
|
||
| : <dfn>"linear"</dfn> | ||
| :: | ||
| Select two texels in each dimension and return a linear interpolation between their values. |
There was a problem hiding this comment.
nit: This makes it sound like, in n dimensions, 2n texels are interpolated, but isn't it 2n?
- Modifies texture sizes to be functions of the block sizes to generalize the tests.
…uweb#805)" (gpuweb#831) This reverts commit 1379f26.
I'm sure I'm missing a lot! We've talked about just saving the entire descriptor in the
GPUobject before, but I don't think I saw another instance where we were doing that.Preview | Diff