Repository navigation
Discussion : Per stage infos in render pipeline descriptor #109
Description
Hi, all
I'm working on render pipeline descriptorization in dawn project now so I want to use this opportunity to address this with your helps.
There are initial proposal in sketch.idl( in PR 47, 9 months ago), but may be other form is better than current one.
Data that needs to be set per shader stage is the shader module, the entry point name, and eventually also specialization constants.
Since WebGPU 1.0 will have VS and FS supported only. I can see several ways things would work in WebGPU:
1 - Having "num shader stages" and arrays for each data. Looks like this:
dictionary WebGPURenderPipelineDescriptor {
sequence<WebGPUShaderStage> stages;
sequence<DOMString> entryPoints;
sequence<WebGPUShaderModule> modules;
...
};
2 - Having an array of sub-descriptor with the data for a shader stage, and "num shader stages". This is what the current sketch.idl does. Looks like this:
dictionary WebGPUPipelineStageDescriptor {
WebGPUShaderModule module;
WebGPUShaderStageEnum stage;
DOMString entryPoint;
// TODO other stuff like specialization constants?
};
dictionary WebGPURenderPipelineDescriptor {
u32 numShaderStages; // optional in WebGPU 1.0
sequence<WebGPUPipelineStageDescriptor> stages;
};
3 - Having a sub descriptor for each stage that's listed as a member of the RenderPipelineDescriptor directly. Looks like this:
dictionary WebGPUPipelineStageDescriptor {
WebGPUShaderModule module;
WebGPUShaderStageEnum stage;
DOMString entryPoint;
// TODO other stuff like specialization constants?
};
dictionary WebGPURenderPipelineDescriptor {
WebGPUPipelineStageDescriptor vertexStage;
WebGPUPipelineStageDescriptor fragmentStage;
};
4 - Having all members per stage directly in RenderPipelineDescriptor. Looks like this:
dictionary WebGPURenderPipelineDescriptor {
WebGPUShaderModule vertexModule;
DOMString vertexEntryPoint;
WebGPUShaderModule fragmentModule;
DOMString fragmentEntryPoint;
}
I prefer the third way myself because validation is simple and clean in this form. What's your opinion?
Activity
Kangz commentedon Nov 7, 2018
Thanks for the discussion! I don't expect WebGPU to have additional shader stages until after v1.0 (and even then probably in extensions at first), so the third approach is the most appealing right now.
kvark commentedon Nov 7, 2018
I don't understand why
numShaderStageswould be needed, given that we havesequencetelling the length. Maybe I'm missing something?Anyhow, 👍 for the third variant.
shaoboyan commentedon Nov 13, 2018
@kvark it is not a real idl format for WebGPU :-) . For dawn project, we need this numShaderStages.
I'll take third variant and thx for your reviewing !
Kangz commentedon Nov 13, 2018
@shaoboyan since we seem to agree on that direction, do you mind making a pull-request that changes sketch.webidl?
kvark commentedon Nov 13, 2018
@shaoboyan can we please discuss
gpuwebissues in the context of a real WebIDL and not a specific implementation, unless explicitly noted? Just to avoid confusion.shaoboyan commentedon Nov 14, 2018
@kvark Sorry about that, modify the original description. I'll care about that.
@Kangz Ok, I'll make a pr for this.
Kangz commentedon Jan 17, 2019
The discussion has been resolved and the IDL updated. Closing this.
Selectively enable quiet-grunt to unbreak vscode grunt integration (g…