Immutable sampler support #356

kvark · 2019-07-04T17:31:00Z

An immutable sampler is one that is a part of the pipeline layout definition, not affected by any bind group binding. The benefits of specifying a sampler as immutable are:

on Vulkan, immutable samplers are part of the API, provided in vkCreateDescriptorSetLayout, so the mapping is trivial.
on D3D12, immutable samplers can be hard-coded into the root signature that corresponds to GPUPipelineLayout. They are represented by the static sampler concept.
on Metal iOS before "MTLFeatureSet_iOS_GPUFamily3_v1" it's impossible to create a sampler with a comparison function, which is often used for shadow map sampling. If it's provided as a part of the pipeline layout, the implementation may hard-code the sampler into the generated MSL shader code, effectively supporting comparison. See Sampler depth comparison before MTLFeatureSet_iOS_GPUFamily3_v1 KhronosGroup/MoltenVK#556 for some real use-case discussion. A as consequence, we may want to document the restriction (for all platforms) that comparison operation is only available on immutable samplers.

If the immutableSampler field of GPUBindGroupLayoutBinding is not nil, and the binding type is "sampler", then this binding is not expected to be provided in GPUBindGroupDescriptor corresponding to the creation of a bind group with this layout.

Preview | Diff

Kangz · 2019-07-05T12:18:16Z

spec/index.bs

+    // For "sampler" binding type, if the actual sampler object is provided here,
+    // it becomes a part of the layout: an "immutable" sampler object, in a sense that
+    // no bind group binding call can affect it.
+    GPUSampler immutableSampler;


Would it make sense for this to be a GPUSamplerDescriptor instead? It doesn't match what Vulkan does but is closer to what D3D12 and Metal do where the sampler descriptor is embedded in the shading language source.

You mean, having a flag there saying that a sampler is immutable? That's not going to be known at pipeline creation time, so I don't see how this would help. Please clarify.

I think Kangz means providing the creation descriptor instead of the platform object to the BindGroupLayout. I'm not sure I like that as much, but I see the appeal of it.

Oh I see. Thanks for clarification! I think that would make sense to do.

this change is now in

litherum · 2019-07-05T16:59:13Z

I don’t think “the mapping is trivial” is sufficient to justify an addition to a Web API. We already have a way of supplying samplers to shaders; I’d like to see some performance numbers that justify this addition before we approve it.

Just like indirect draw arguments, sampler comparison functions are present on all hardware we’re targeting for WebGPU. We should just require support for them.

kvark · 2019-07-05T17:24:51Z

@litherum "the mapping is trivial" is not by itself sufficient to justify the addition. I agree. We are weighting many factors here. One of them is how difficult it is to map to the native APIs. We know the answer to this one.

Another factor, as you mentioned, is what does it give us in terms of performance. I haven't done the benchmarks, but I could find this reference from AMD in 2016, see slide 14:

Immutable Samplers can be constructed by SALU instructions instead of SMEM loads. Reduces the amount of latency in the shader. SALU pipe is mostly under-utilized.

I imagine the same reasoning can be applied to Metal, since it supports constexpr samplers in MSL?

Just like indirect draw arguments, sampler comparison functions are present on all hardware we’re targeting for WebGPU. We should just require support for them.

Is there a place where you have those hardware requirements specified? IIRC, indirect arguments on iOS require 9.0, which covers a much wider range of devices than "MTLFeatureSet_iOS_GPUFamily3_v1". For example, iPhone4S can run iOS 9.0, but MTLFeatureSet_iOS_GPUFamily3_v1 is only available in iPhone6S, so there is about 2 generations of a difference here.

damyanp · 2019-07-12T19:44:47Z

I’d like to see some performance numbers that justify this addition before we approve it.

I'm trying to dig up some info on this from the d3d perspective.

kainino0x · 2019-07-12T21:06:30Z

Rebased over #365.

grorg · 2019-07-15T19:10:26Z

This was discussed at the 15 July 2019 teleconference.

damyanp · 2019-07-15T19:28:35Z

I’d like to see some performance numbers that justify this addition before we approve it.

I'm trying to dig up some info on this from the d3d perspective.

Here's what I heard back:

"They are simply a massive convenience. You can define your samplers directly in your shader and not have any external code have to worry about anything."

kvark · 2019-07-15T19:34:54Z

Thanks @damyanp !
I would like to see immutable samplers supported by the API at some point. It looks like the group wants to see hardware requirements or performance benefits for this to happen now. For the former, Apple is fine with iPhone 6S as a baseline, and for the latter - there is no concrete evidence.
Closing then...

devshgraphicsprogramming · 2019-08-22T15:59:31Z

Those things (immutable samplers) are a tad faster on Android IIRC

Also easier to implement on an OpenGL backend, OpenGL 4.5 and below has no mutable samplers that you can combine in a shader, the combining happens on the API side.

Full mutable (a shader texture(image,sampler) functionality) is impossible to pull off in OpenGL (except for 4.6)

kvark added the investigation label Jul 4, 2019

Kangz reviewed Jul 5, 2019

View reviewed changes

kvark force-pushed the immutable-sampler branch from 25a6c42 to c585541 Compare July 5, 2019 13:27

Kangz approved these changes Jul 5, 2019

View reviewed changes

Support immutable samplers

327f77a

kainino0x force-pushed the immutable-sampler branch from c585541 to 327f77a Compare July 12, 2019 21:05

kvark closed this Jul 15, 2019

kvark mentioned this pull request Jul 27, 2021

Compatibility with iOS simulator webgpu-native/webgpu-headers#92

Closed

kainino0x mentioned this pull request Jul 27, 2021

What OSes and hardware are we targeting? #1069

Closed

Immutable sampler support #356

Immutable sampler support #356

Uh oh!

Conversation

kvark commented Jul 4, 2019 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kangz Jul 5, 2019

Choose a reason for hiding this comment

Uh oh!

kvark Jul 5, 2019

Choose a reason for hiding this comment

Uh oh!

magcius Jul 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvark Jul 5, 2019

Choose a reason for hiding this comment

Uh oh!

kvark Jul 5, 2019

Choose a reason for hiding this comment

Uh oh!

litherum commented Jul 5, 2019

Uh oh!

kvark commented Jul 5, 2019

Uh oh!

damyanp commented Jul 12, 2019

Uh oh!

kainino0x commented Jul 12, 2019

Uh oh!

grorg commented Jul 15, 2019

Uh oh!

damyanp commented Jul 15, 2019

Uh oh!

kvark commented Jul 15, 2019

Uh oh!

devshgraphicsprogramming commented Aug 22, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

kvark commented Jul 4, 2019 •

edited by pr-preview bot

Loading

magcius Jul 5, 2019 •

edited

Loading