W3C home > Mailing lists > Public > public-gpu@w3.org > September 2017

Re: Pipeline objects open questions

From: Myles C. Maxfield <mmaxfield@apple.com>
Date: Mon, 11 Sep 2017 20:44:05 -0700
Cc: public-gpu <public-gpu@w3.org>
Message-id: <245B0E16-72FD-4CE6-B0F9-2AE562CFDA80@apple.com>
To: Corentin Wallez <cwallez@google.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), 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?
The desire here is valid. Metal doesn¡¯t have any concept of a pipeline cache, but it does have an intermediate form that shaders can be in (i.e. if you create an Xcode project and add a .metal file to it, Xcode will compile to this at build-time). Caching these would speed up the initialization of a WebGPU webapp.

However, both D3D12 and Vulkan expose this by letting the application access the raw bytes of the cache (presumably so the application can serialize them to disk). If these objects are going to hold machine code for compiled shaders, letting them round-trip through arbitrary JavaScript would be unacceptable from a security perspective. Instead, the only way this could work is if the webapp was delivered an opaque handle (or cookie) which had no intrinsic meaning, but was used as a key in an internal map the browser maintains (and the browser prunes at implementation-defined times with implementation-dependent pruning criteria).

But if the browser is going to hold on to these objects internally anyway, there isn¡¯t really any value in going through the webapp at all. Instead of making the webapp author write new code to get performance, we should just make fast performance the default. These pipeline caches would work best if the browser internally always used them for all WebGPU apps.
> Should the type of the indices be set in RenderPipelineDescriptor? If not, how is the D3D12 IBStripCutValue chosen?
> Should the vertex attributes somehow be included in the PipelineLayout so vertex buffers are treated as other resources and changed in bulk with them?
> Does the sample count of the pipeline state come from the RenderPass too?
> 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?
> About Vulkan¡¯s VkPipelineDepthStencilStateCreateInfo::depthBoundTestEnable and D3D12's D3D12_DEPTH_STENCIL_DESC1::DepthBoundsTestEnable? Should ¡°depth test enable¡± be implicit or explicit?
> What do you all think about these?
> Corentin

Received on Tuesday, 12 September 2017 03:44:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:22 UTC