- From: Myles C. Maxfield <mmaxfield@apple.com>
- Date: Mon, 11 Sep 2017 17:30:04 -0700
- To: Corentin Wallez <cwallez@google.com>
- Cc: public-gpu <public-gpu@w3.org>
- Message-id: <BA4CA84A-88AD-4DFF-9BE8-A39DF56EE9CD@apple.com>
> On Sep 8, 2017, at 12:24 PM, Corentin Wallez <cwallez@google.com> wrote: > > Hey all, > > While what goes into pipeline objects is mostly clear (see this doc <https://github.com/gpuweb/gpuweb/blob/master/design/Pipelines.md>), there is still a bunch of open questions: > How do we take advantage of the pipeline caching present in D3D12 and Vulkan? Do we expose it to the application or is it done magically in the WebGPU implementation? No comment from us right now. We need more time to discuss internally. > Should the type of the indices be set in RenderPipelineDescriptor? If not, how is the D3D12 IBStripCutValue chosen? I’m not sure that triangle strips are necessary in the first place for the MVP. Also, I’m not sure how Dzmitry fit 0xFFFFFFFF into a u16? Maybe I’m misunderstanding. > Should the vertex attributes somehow be included in the PipelineLayout so vertex buffers are treated as other resources and changed in bulk with them? I agree with the comments previously made here. > Does the sample count of the pipeline state come from the RenderPass too? I’m not sure what you mean by “come from.” Are you asking whether or not the render pass must include the sample count in addition to the pipeline state including the same sample count? If you are asking that, I don’t see why we should require redundant information. The sample count must at least be present in the pipeline state because that’s where Metal looks when it needs to configure the rasterizer. > Should enablement of independent attachment blend state be explicit like in D3D12 or explicit? Should alpha to coverage be part of the multisample state or the blend state? Similar to above, there’s no reason to require redundant information. Also similar to above, I’m not sure if alpha-to-coverage is necessary for the MVP. > About Vulkan’s VkPipelineDepthStencilStateCreateInfo::depthBoundTestEnable and D3D12's D3D12_DEPTH_STENCIL_DESC1::DepthBoundsTestEnable? Should “depth test enable” be implicit or explicit? I want to be clear about what you’re asking. It sounds like you’re asking for us to choose between two cases: A boolean variable (depthBoundTestEnable), which determines whether or not the implementation cares about another n-state variable (less-than, less-than-or-equal-to, equal, etc.) An (n+1)-state variable (never, less-than, less-than-or-equal-to, equal, etc.) I don’t think it matters very much, but option 2. seems cleaner. > What do you all think about these? > > Corentin
Received on Tuesday, 12 September 2017 00:30:29 UTC