Skip to content

Add minmax-sampling feature #1283

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

Add minmax-sampling feature #1283

wants to merge 4 commits into from

Conversation

kvark
Copy link
Contributor

@kvark kvark commented Dec 8, 2020

Closes #1267

This is useful for building hierarchical depth bounds, as one example.

Hardware support:

Note: min/max sampling shouldn't be considered "filtering" for the purpose of validation.

TODO:

  • figure out which formats support this, potentially add a column to our format table.
  • determine if it's a filter mode, or something entirely different. Can a sampler be linearly magnifying but minmaxing the minification? In D3D12 it can, it seems, but maybe we don't need that.
  • determine if a separate sampler binding type is needed

Preview | Diff

@kvark kvark added the feature request A request for a new GPU feature exposed in the API label Dec 8, 2020
@github-actions
Copy link
Contributor

github-actions bot commented Dec 8, 2020

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
a979cf8

@@ -1375,6 +1375,7 @@ enum GPUFeatureName {
"pipeline-statistics-query",
"texture-compression-bc",
"timestamp-query",
"minmax-sampling",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is minmax sampling allowed for uint, int textures, but also for comparison samplers?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The minmax feature in vulkan doesn't require support for any integer formats, so I assume we wouldn't support any. It also can't be used with comparison samplers apparently (kinda weird).

If the format is a depth/stencil format, this bit only specifies that the depth aspect (not the stencil aspect) of an image of this format supports min/max filtering, and that min/max filtering of the depth aspect is supported when depth compare is disabled in the sampler.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be, but getting the stats for this is hard :(
For now the spec only allows it on a few selected formats (see last commit).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, that's not a lot of formats.

@@ -7239,6 +7257,22 @@ The following enums are supported if and only if the {{GPUFeatureName/"timestamp
* {{GPUQueryType/"timestamp"}}
</dl>

## <dfn dfn-type=enum-value dfn-for=GPUFeatureName>minmax-sampling</dfn> ## {#minmax-sampling}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## <dfn dfn-type=enum-value dfn-for=GPUFeatureName>minmax-sampling</dfn> ## {#minmax-sampling}
## <dfn enum-value for=GPUFeatureName>minmax-sampling</dfn> ## {#minmax-sampling}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should change this across all features, consistently (as a follow-up)

@github-actions
Copy link
Contributor

github-actions bot commented Dec 8, 2020

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
2c2a89f

@@ -1375,6 +1375,7 @@ enum GPUFeatureName {
"pipeline-statistics-query",
"texture-compression-bc",
"timestamp-query",
"minmax-sampling",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, that's not a lot of formats.

@kvark kvark marked this pull request as draft December 8, 2020 18:27
@github-actions
Copy link
Contributor

github-actions bot commented Dec 8, 2020

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
53bd4d1

@github-actions
Copy link
Contributor

github-actions bot commented Dec 8, 2020

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
eb1c48d

@kvark
Copy link
Contributor Author

kvark commented Dec 8, 2020

Thank you for the quick and detailed reviews! We have now gone through a few iterations, and the spec is not quite the same as it was in the first draft.
There appear to be some interesting interactions between the filtering and reduction modes (which is a new enum added in the last commit). In Vulkan:

The reduction mode is orthogonal to the minification and magnification filter parameters. The filter parameters are used to identify the set of texels used to produce a final filtered value; the reduction mode identifies how these texels are combined.

So it sounds like a format still has to be filterable, even if the min/max reduction mode is used. This mostly affects "r32float", which I tentatively marked as enabled for min/maxing, even though one technically can do it today, since filtering is not supported (i.e. they get a WebGPU validation error because of filtering requirements).

@kvark kvark marked this pull request as ready for review December 8, 2020 18:51
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.

OK; as I said on the issue I wasn't sure whether it was tied to filterability or not.

I should have noticed that this should have defined a reduction mode instead of a filter mode, whoops.

|s|.{{GPUSampler/[[descriptor]]}}.{{GPUSamplerDescriptor/compare}} is `null` or undefined.
Otherwise, set it to `true`.
1. Set |s|.{{GPUSampler/[[isMinMax]]}} to `false` if
|s|.{{GPUSampler/[[descriptor]]}}.{{GPUSamplerDescriptor/reduction}} is {{GPUReductionMode/"weighted-average"}}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems kind of backward, I think it's easier to read if it says set it to true if it's "minimum" or "maximum"

1. Set |s|.{{GPUSampler/[[isFiltering]]}} to `false` if none of {{GPUSamplerDescriptor/minFilter}},
{{GPUSamplerDescriptor/magFilter}}, or {{GPUSamplerDescriptor/mipmapFilter}} has the value of
{{GPUFilterMode/"linear"}}. Otherwise, set it to `true`.
1. Set |s|.{{GPUSampler/[[isComparison]]}} to `false` if
|s|.{{GPUSampler/[[descriptor]]}}.{{GPUSamplerDescriptor/compare}} is `null` or undefined.
Otherwise, set it to `true`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just say undefined; JS null and undefined both get converted to IDL undefined
https://heycam.github.io/webidl/#es-dictionary

I would probably flip this to say "true if compare is defined" or "is specified" or "is not undefined".

Wish we could come up with a better phrasing than "otherwise set it to true". Like "set isComparison to (s.descriptor.compare ≠ undefined)" maybe?

@@ -3555,7 +3573,7 @@ A {{GPUProgrammableStageDescriptor}} describes the entry point in the user-provi
: {{GPUSamplerBindingType/"comparison"}}
:: the |binding| is a comparison sampler
: {{GPUSamplerBindingType/"minmax"}}
:: the |binding| is a min/max sampler
:: the |binding| is a non-comparison sampler
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe have "filtering or non-filtering or minmax" as one case, or just "otherwise".

@@ -2349,7 +2355,7 @@ match one texel.
<script type=idl>
enum GPUFilterMode {
"nearest",
"linear"
"linear",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Briefly considering if we try to come up with a word other than linear, since this also describes minmax filters which aren't exactly "linear"? I'm not sure what it would be; "nearest"/"linear"(/"cubic") is well understood terminology. I think they're clearest.

Vulkan has an extension to use min/max with "cubic", too, fwiw: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#textures-texel-cubic-filtering

@Kangz
Copy link
Contributor

Kangz commented Dec 10, 2020

nit: are we sure we want to have this in the spec given it seems a very niche or advanced feature? I'm worried you both have spend significant time on this when it is nowhere close to the critical path to getting WebGPU out :)

@kvark
Copy link
Contributor Author

kvark commented Dec 10, 2020

I just needed a warm-up before starting #1293 :)
Seriously though, I don't yet know if it's needed for MVP.
We don't have it implemented, although it's not going to be too hard to add.
Ideally, we'd reach out to ISVs and ask them about a number of features that we are considering for MVP, including this one, and make a decision based on this feedback.

@kvark kvark added this to the post-V1 milestone Nov 22, 2021
@kainino0x kainino0x marked this pull request as draft August 25, 2022 01:35
ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022
…1417)

This PR adds unimplmented stubs for the read-write-modify atomic operations.

 * `atomicAdd`
 * `atomicAnd`
 * `atomicCompareExchangeWeak`
 * `atomicExchange`
 * `atomicMax`
 * `atomicMin`
 * `atomicOr`
 * `atomicSub`
 * `atomicXor`

Issue gpuweb#1275, gpuweb#1276, gpuweb#1277, gpuweb#1278, gpuweb#1279, gpuweb#1280, gpuweb#1281, gpuweb#1282, gpuweb#1283
@kainino0x kainino0x added the api WebGPU API label May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api WebGPU API feature request A request for a new GPU feature exposed in the API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Integer Sampling & Sampler Reduction Modes
3 participants