kc3-lang/angle

2021-02-12T14:14:02

Vulkan: Optimize glMemoryBarrier Previous to this change, glMemoryBarrier was processed as it is issued. This made it impossible to know whether a draw call would follow or a dispatch call, and what resources it would use. The render pass was conservatively broken due to this limitation. To address this limitation, handling of glMemoryBarrier is deferred until the next draw or dispatch call. Note that glMemoryBarrier acts as two barriers: - An execution+memory barrier: shader writes are made visible to subsequent accesses - Another execution barrier: shader accesses are finished before subsequent writes An important observation is that for most resources, ANGLE actually necessarily has to issue memory barriers automatically to conform with Vulkan. In terms of memory barrier thus, ANGLE already does the right thing except for when there's no binding change. This means WaW hazards (i.e. storage buffer and image writes) with no binding change require a memory barrier as a result of glMemoryBarrier. In all other cases, it's enough for glMemoryBarrier to break the render pass if necessary and ensure that corresponding bindings are marked dirty (for the execution or memory barriers to happen automatically later). Bug: angleproject:5070 Change-Id: Ide359c43362f8a78805ecf797a91de7aa79221f9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2693473 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>