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

I think this will have impact on the already complex matrix of GPUSupportedLimits.

Have we considered making setVertexBuffer take an ArrayBufferSource? Then we don't need to change the limits.

I didn't take a look at the D3D or Vulkan backends yet so maybe that is the motivation? On Metal, this is as simple as calling setVertexBytes: / setFragmentBytes:

Assuming that push constants would be implemented using D3D12's root constants...

If I'm not mistaken, D3D12 has a fixed (per-device?) amount of space in the root signature. In shipping WebGPU, the WebGPU implementation gets to decide how to use that space.

For example, if the WebGPU Pipeline Layout includes 2 textures, the WebGPU implementation can place those 2 texture descriptors directly inside the D3D12 root signature. Or, alternatively, the WebGPU implementation can choose to put both texture descriptors into a descriptor table, and make the root signature point to the descriptor table. The WebGPU implementation has freedom here to use this fixed root signature space as it desires.

Okay, now let's add in support for push constants. Push constants would also live directly within the fixed root signature space. But what if all the root signature space is already occupied (e.g. by those texture descriptors from the above paragraph)?

Even if WebGPU only allows a single push constant, that doesn't actually solve the problem. The root signature space may be 100% occupied by descriptors, leaving no space at all for push constants.

There are a variety of potential solutions to this problem:

• Make push constants space allocation be best-effort. If there isn't space within the root signature, fail to set the push constant. Different devices will fail in different situations.
• Tell every implementation that it must leave X bytes of extra space in the root signature for push constants, where "X" is a literal value spelled out in the spec. This is unfortunate because it pessimizes - the app might not need all X bytes, and the remaining bytes might be better spent on descriptors
• Have the app request how much push constant space it needs, within the WebGPU Pipeline Layout, and add platform-agnostic validation rules to make sure the app doesn't ask for too much space. Inventing such validation rules will be tricky, because the rules would have to balance the freedom of WebGPU implementations to place descriptors freely, with the desire to allow applications to request as much push constant memory as they want/need. Another reason I don't like this option is that, if the application requests too much push constant space and pipeline layout creation fails, that doesn't mean they can't access data of the requested size, but it instead just means they can't access data of the requested size as push constants.
• (My favorite option): Let push constants be an implementation detail, rather than an explicit part of the WebGPU API, and treat the root signature space as just another part of the pipeline layout.
  • As @mwyrzykowski suggests, the group could add a new method to GPUBindingCommandsMixin (as a sibling to setBindGroup()) that accepts immediate data (in the form of an ArrayBuffer) rather than a BindGroup. (Or, maybe, alternatively, this could be an overload of createBindGroup() that takes immediate data.)
  • The group could even add a maxBindingSize field to GPUBufferBindingLayout, which would allow the the WebGPU pipeline creation routine can know whether the data is small enough that it can guarantee that the data fits into push constant space.
  • Limits accounting doesn't change at all, which is appealing

Previously conducted performance analysis of push constants:

• Investigation : Push Constants #75 (comment)
• Investigation : Push Constants #75 (comment)
• Investigation : Push Constants #75 (comment)

Let push constants be an implementation detail, rather than an explicit part of the WebGPU API, and treat the root signature space as just another part of the pipeline layout.

Just point out possible implementation issues I observed:

• On Metal this works fine since it is super align with metal API SetVertexBytes() and so on. But it might have some problem for Vulkan and D3D12. Both Vulkan and D3D12 defines push constants or root constants in pipelineLayout. When calling SetPushConstants(), we need to ensure the pipeline has such push constants range. I think this implementation hints that we need to allocate remain root space as root constants and we need to always keep a internal binding point for each bind group to handle the case that "User setPushConstants() but we don't have enough space, so fallback to a buffer".

I think this implementation hints that we need to allocate remain root space as root constants and we need to always keep a internal binding point for each bind group to handle the case that "User setPushConstants() but we don't have enough space, so fallback to a buffer".

It sounds like D3D and Vulkan can be optimized to not use a buffer when the push constants are small enough and there is space. With Metal, we always need to reserve a buffer slot for the push constants. Though it would be possible to map them all into one buffer slot.

Abstracting this concept seems to further justify that the term 'push constants' does not necessarily need to exist in WebGPU. Rather, the D3D and Vulkan backends can implement small, dynamic setBindGroup calls into push constants and on Metal, we would use set[Vertex/Fragment]Bytes unless the data is large, then we would make a buffer

If you tie push constants to specifically render pipelines, then you can't use them for compute shaders (and later, other types of pipelines), which would be unfortunate.

@JMS55

Yeah, people in this thread are using a variety of different terminology. Above, when people say "setVertexBytes()" or "setFragmentBytes()," I believe they are referring to the Metal functions of the same name, as an example of a function that takes immediate data (rather than a method taking resources or bind groups). Even in Metal, there's a way to supply immediate data to compute pipelines.

tl;dr: Thinking deeper, I think the only way it can work in Vulkan is either to just not add the feature at all, or add an explicit API for it.

I think the biggest unanswered question here regarding "let push constants be an implementation detail" is this: Consider such a program:

let renderPassEncoder = commandEncoder.beginRenderPass(...);
renderPassEncoder.setPipeline(...);
renderPassEncoder.setImmediateData(new Int32Array([42])); // Unclear how this will interact with bind groups, but let's assume that problem is surmountable...
renderPassEncoder.draw(...);
renderPassEncoder.setImmediateData(new Int32Array(/* a very long array */));
renderPassEncoder.draw(...);

The question is: What should the code in the shader be to handle both of these cases? In the first case, we'd want to promote the 42 to a push constant (probably? AFAICT it hasn't been demonstrated whether push constants are actually consistently better to use cross-platform), but in the second case, the data is too big to fit in push constants. Both situations would (probably) need to be supported by a single shader - setPipeline() is only called once in the above code sample.

In SPIR-V, the text of the shader is actually different depending on whether or not you're accessing a push constant or not. For example, in GLSL (which I'm using here just as a readable form of SPIR-V), you'd either have this:

layout(push_constant) uniform Constants {
	int pushConstantData;
};

Or this:

layout(set = 0, binding = 0) uniform Constants {
	int uboData;
};

If we operate under the constraint that no amount of recompilation is allowed to happen while commands are being recorded into the render pass - not even supplying specialization constants - then the only way this can work is if both blocks are present in the shader, and each access to the data is guarded by a flag - in software - to determine whether the data was bound to pushConstantData or uboData. Adding this selection in software probably defeats the whole purpose of trying to use push constants in the first place. It's probably a dealbreaker. (But its performance should probably be measured nevertheless.)

Assuming it is in fact a dealbreaker, it seems like the only way this could ever work (again, assuming that the committee does want to make it work, which I'm still not convinced has been sufficiently justified) would be to come up with a system where the implementation can guarantee that the immediate data being set by the app will fit into push constant space. This is why I suggested a maxBindingSize field within the pipeline layout. Such a field could allow the implementation to know that the data provided by the application will fit into push constants.

But there's even an additional problem - what about the following program:

let renderPassEncoder = commandEncoder.beginRenderPass(...);
renderPassEncoder.setPipeline(...);
renderPassEncoder.setImmediateData(new Int32Array([42]));
renderPassEncoder.draw(...);
renderPassEncoder.setBindGroup(/* clobbering the immediate data above */);
renderPassEncoder.draw(...);

How should this work, assuming no amount of recompilation is acceptable? Imagine the bind group contains a buffer whose contents is populated by a previous compute shader - the CPU has never seen this data, and therefore such data cannot be hoisted to push constants. There would have to be some way, at the API level, to distinguish the immediate data from the bind group data, so that the shader wouldn't have to handle both cases in software at runtime.

I think the only way this could work is to add a new type of descriptor in the bind group layout. That way, an entry in the bind group layout could either refer to a buffer, or refer to immediate data, but not both. Any data set by immediates for one draw call would be incapable of being clobbered by a GPU-populated buffer for a subsequent draw call - thereby allowing the shader compiler to know that it's safe to only emit the layout(push_constant) block above.

So then that begs the question: What should this new type of descriptor in the bind group layout be named? Perhaps it should be named ... "push constant"...

This is turning into a bit of a bikeshed opportunity, but I'll add my two cents to the jar:

• I do not want shader recompilation at command buffer runtime, after pipelines have been created. This would be a very unfortunate thing to require implementations to do, after we spent the effort to put PSOs into the spec. Expensive synchronous recompilations cause stalls that we are trying to avoid in WebGPU.
• The big value I see in push constants is boot-strapping indices into other buffers or bind groups; this is where I would expect to see them come in the most handy.
• Just because D3D12 offers an ability to embed some maximum number of root constants, does not mean that going all the way up to that number is necessarily free. My proposal was limited to 4 u32's for a reason.
• Making push constants transparent to the application would be extra difficult to support uses that mix both bind groups and push constants. See below for more details.
• Push constants might be especially relevant when talking about newer tools like "bindless", where shaders index arrays of resources like textures or buffers.

To give a bit of an unprompted history lesson and awareness of how these features are implemented in practice...

The simplified AMD interpretation of push constants (not applicable to all drivers and hardware, just giving one mental model): The hardware has some general-purpose 32-bit scalar registers (SGPRs); these registers are active storage for threads, but also can be initialized with user constants set up by the hardware that launches threads. Some of these registers are used by the driver itself for internal purposes (e.g. the "base draw offset" feature from Vulkan would get passed by an SGPR), some of them are used by the driver to implement binding models (D3D12 CBVs might get mapped directly to an SGPR), and some of them are used to store memory addresses to binding tables (e.g. if you have a lot of textures, the driver will allocate a block of memory which has the texture descriptors, and store a pointer to the table in an SGPR; these are D3D12's "descriptor tables").

The D3D12 idea was that all root signature parameters (root constants, CBVs, descriptor tables) would map to SGPRs; however, as the driver sometimes needs some for its own purposes, this isn't a 1:1 mapping, and sometimes the driver has to jettison some of the parameters to a memory block and do some finagling to rearrange all of the binding updates. Note that since the usage of an SGPR is arbitrary (it can contain a memory address or a value, just depending on how it's used), the usage needs to be determined at root signature time; in practice, the AMD compiler effectively reserves a few driver SGPRs that work across all platforms.

So, in order to make "transparent push constants" work, we can't simply replace the first N bytes of a uniform buffer of a bind group with immediate data; using it with a bind group will require a pointer in the SGPRs, while using it with push constants will require the values in SGPRs. Instead, we'll need syntax that lets us optimistically compile the first N push constants to SGPRs, and then the rest get jettisoned to a memory buffer. This is enabled a bit more by the extra pipeline layout field so we know up-front what will fit, but it still seems more complicated than just having a small fixed-size limit in the specification. We can always expand to support bigger sizes through emulation later.

The big value I see in push constants is boot-strapping indices into other buffers or bind groups

shaders index arrays of resources like textures or buffers.

I think we have to be careful here - if the biggest use case is simply "make some indices available to a shader" then a simple API convenience method would be sufficient, without changing the binding model or adding push constants at all.

(I just realized that we already have that simple API convenience method: GPUQueue.writeBuffer(). I think the burden of proof needs to be "why push constants in addition to writeBuffer()?"

• CW: Sounds fine. WGPU has it, MikeW agreed… it’s clear it will happen at some point. People can start experimenting, even if it’s not 100%. There will be output on the agenda request for a Pacific time meeting, then.

It would still be nice to get rid of the typed method names which seem out of place with the rest of the specification:

        void setImmeidateDataU32(uint32_t offset, uint32_t value);
        void setImmediateDataI32(uint32_t offset, int32_t value);
        void setImmediateDataF32(uin32_t offset, float32_t value);

and maybe allow something more flexible like:

void setImmediateData(uint32_t offset, GPUPipelineConstantValue value, USVString type);

Not sure what @shaoboyan thinks

Unless we expect that we'll be adding a lot more data types I don't see any particular advantage to passing the type as an enum, and it probably adds some additional work for implementors to do the value cast in the implementation rather than allowing the WebIDL layer to handle it for you. Plus I think the variant with separate methods for each type is more WASM-friendly as well?

I proposed the original wrapper functions as optional sugar, and I'm fine with them being removed in favor of an ArrayBuffer interface if we can't agree on them. We already require that users construct ArrayBuffers for writeBuffer so it's not like a user should have any difficulty figuring it out.

I'm a fan of using IDL to handle type conversion. I think immediate data is a perf focus API so I prefer avoiding any non-necessary steps.

Agreed. Here's a benchmark of a f32-to-u32 reinterpretation, a common math operation one would do with TypedArray. https://jsbench.me/2vlxcmotny/1

According to this benchmark, I think the perf gap between typed data and constructed array buffer is not trivial. So I support specific typed APIs

adds some additional work for implementors to do the value cast in the implementation

I'm slightly preferred to put type conversion in IDL layer so that we might benefit from future IDL opts. And again, this might help the uploading perf compared with extra enum variable.

The question to me is comparing:

setImmediateDataF32(0, 123.0);
setImmediateDataF32(4, 456.0);
setImmediateDataF32(8, 789.0);
setImmediateDataF32(12, 101112.0);

and

setImmediateData(0, new Float32Array([123.0, 456.0, 789.0, 101112.0]));

There are already multiple tricks to cut down on array buffer allocation cost (e.g. allocate one large buffer which you reuse). I also wish that JS implementations would see this as an opportunity to improve TypedArray performance, but I probably can't have my wish here.

Internally in Firefox's WebGL implementation, we convert all calls to e.g. uniform1i into something called UniformData:
Content process:
https://searchfox.org/mozilla-central/rev/0b1d02b2cb5736511139cf0e40b318273e825899/dom/canvas/ClientWebGLContext.h#1910
Gpu process:
https://searchfox.org/mozilla-central/rev/0b1d02b2cb5736511139cf0e40b318273e825899/dom/canvas/WebGLContextGL.cpp#1281

This very nicely predisposes me to setImmediateData being more generic, rather than having typed entrypoints. :)