Re: Pipeline objects open questions

Ben,

> With regard to your test with strip cut index, I think it is dangerous to
rely on a non-specced behavior like that.

If only, you know, we had a "specced" behavior defined for D3D12. The MSDN
pages are rather scarce on details (
https://msdn.microsoft.com/en-us/library/windows/desktop/dn986732(v=vs.85).aspx).
If I read exactly what it says, then my test case should not have worked.
My understanding is that the best specification of D3D12 is the HLK test
suite. Could you check the source of the corresponding test (
https://msdn.microsoft.com/en-us/library/windows/hardware/dn942192(v=vs.85).aspx)
to see if the case using 0xFFFFFFFF value with 16-bit buffer is covered?
I'm hoping to see this behavior analogous to stencil tests. One can have a
reference value of 0x34 matching the stencil buffer value of 0x04 if the
corresponding stencil read mask is 0x0F, for example.

> Are we wanting to allow multiple index types in the MVP (both 16 and 32)?
I realize that there are bandwidth limitations etc driving people’s
decisions here, but I am skeptical that this design point is something that
gives us lock-in if we just choose 32 bit for the time being.

It's a bit important since it affects the pipeline creation API. Surely we
can (and will) break the API after MVP, but we better have strong reasons
for it.

Myles,

> Also, I’m not sure how Dzmitry fit 0xFFFFFFFF into a u16? Maybe I’m
misunderstanding.

My index buffer is 16-bit and has a value of 0xFFFF. I used `
*D3D12_INDEX_BUFFER_STRIP_CUT_VALUE_0xFFFFFFFF`* for PSO creation and got
it respecting the 16-bit value.

> Also similar to above, I’m not sure if alpha-to-coverage is necessary for
the MVP.

Do you find it controversial? If not, let's have it in the MVP.

> It sounds like you’re asking for us to choose between two cases:

I see the question caused some confusion. Depth bounds test != depth test.
I voted for both to be explicit, potentially by using WebIDL optional
dictionary entries/default values semantics.

Regards,
Dzmitry

On Mon, Sep 11, 2017 at 8:30 PM, Myles C. Maxfield <mmaxfield@apple.com>
wrote:

>
>
> 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:
>
>    1. 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.)
>    2. 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
>
>
>