| commit | 2cd06ce1b33cc86e13e6df8dbcacc42bb8fe67ba | [log] [tgz] |
|---|---|---|
| author | Albin Bernhardsson <albin.bernhardsson@arm.com> | Tue Nov 07 18:25:27 2023 +0000 |
| committer | Dawn LUCI CQ <dawn-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Nov 07 18:25:27 2023 +0000 |
| tree | a700373e065755a3069e466e7fad62eb3f1eb6f8 | |
| parent | 92dc20779e7bbf52ef3ea63a7794126e0066aa30 [diff] |
Improve Vulkan synchronization Track resources per shader stage by using the visibility flags in the bind group layout. This means we can insert more precise barriers, allowing vertex and/or compute to execute in parallel with fragment shading. Eg. if we have two render passes where the second render pass samples an image rendered in the first in the fragment shader, this would previously result in a FRAGMENT->VERTEX|FRAGMENT|COMPUTE barrier as a texture can be sampled in any shader stage and only the usage is considered when inserting the barrier. By considering the shader stages, we can instead insert a FRAGMENT->FRAGMENT barrier. Fix an issue where empty image memory barriers cause a TOP_OF_PIPE->TOP_OF_PIPE barrier. On its own, this is a NOP, but when merged with other barriers, the TOP_OF_PIPE in the destination stages could cause unnecessarily conservative barriers. Previously, all barriers in a sync scope were merged into one pipeline barrier. Eg. if we have a render pass with one resource being used in a vertex shader and was last written in compute (eg. compute skinning), and a resource used in a fragment shader and last written to by a render pass (eg. ambient occlusion), merging these COMPUTE->VERTEX and FRAGMENT->FRAGMENT barriers would lead to a COMPUTE|FRAGMENT->VERTEX|FRAGMENT barrier, inadvertently introducing an unnecessary FRAGMENT->VERTEX dependency and disallowing parallel execution. Change this so that all barriers which contain a vertex stage in the destination stages are merged into one pipeline barrier, and all remaining barriers into another. In a Sponza test scene this reduces frame times by 17% on a Mali-G78 device. Bug: dawn:851 Change-Id: I50e2f00f845670d7f161a0afa6579eba6057afa3 Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/151340 Reviewed-by: Austin Eng <enga@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Kokoro: Kokoro <noreply+kokoro@google.com> Commit-Queue: Albin Bernhardsson <albin.bernhardsson@arm.com>
Dawn is an open-source and cross-platform implementation of the work-in-progress WebGPU standard. More precisely it implements webgpu.h that is a one-to-one mapping with the WebGPU IDL. Dawn is meant to be integrated as part of a larger system and is the underlying implementation of WebGPU in Chromium.
Dawn provides several WebGPU building blocks:
webgpu.h version that Dawn implements.webgpu.h.Helpful links:
Developer documentation:
User documentation: (TODO, figure out what overlaps with the webgpu.h docs)
(TODO)
BSD 3-Clause License, please see LICENSE.
This is not an officially supported Google product.