Skip to content

A
angle
Switch branch/tag
  1. 22 Jul, 2020 4 commits
    • Vulkan: Fix invalidate + deferred clear · f6659b3d
      Shahbaz Youssefi authored 
      Imagine the following scenario:

1. Clear draw framebuffer
2. Invalidate draw framebuffer
3. Copy from read framebuffer into texture that is attached to draw
   framebuffer
4. Draw again into draw framebuffer

At step 2, FramebufferVk::syncState is called which extracts the clear
and stores it in mDeferredClears, but since the framebuffer description
hasn't changed, a new render pass is not started.

At step 3, the texture attached to the draw framebuffer is used as copy
destination, but its clear which is stored in the (apparently
irrelevant) draw framebuffer is not flushed.

At step 4, a new render pass is started which clears the draw
framebuffer, trampling the copy in step 3.

This change makes sure invalidate results in a flushDeferredClears().
With glInvalidateFramebuffer() (not glInvalidateSubFramebuffer()), the
deferred clears for invalidated framebuffers are discarded first.

It is unknown whether there are similar situations where syncState
gathers deferred clears, but they are not flushed before the attachments
are updated outside the framebuffer.  To catch similar bugs in the
future, assertions are added to FramebufferVk::syncState such that if a
dirty bit is set for the contents of an attachment, we can make sure
there are no prior deferred clears stored for that attachment.

Bug: angleproject:4862
Change-Id: Idb1a08b53e7f011f0fc9a54d478289030b6d77a8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2308034Reviewed-by: 's avatarShahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: 's avatarCourtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
    • Vulkan: Fix deferred clears and noop clear and blit · c757e607
      Shahbaz Youssefi authored 
      Imagine the following situation:

1. Clear draw framebuffer
2. Noop operation on the framebuffer (Clear, ClearBuffer,
   BlitFramebuffer with flags specifying non-existing attachments)
3. Change framebuffer's attachment
4. Draw into framebuffer

At step 2, FramebufferVk::syncState was called before noop-ing the
operation.  During syncState, deferred clears were stored in the
framebuffer and weren't flushed because the actual operation was not
performed.

At step 4, the deferred clear meant for the prior attachment gets
applied to the new attachment.

Bug: angleproject:4865
Change-Id: I5b096bacf00356b4dccd4cbc9561b87b1bb557d8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2309224Reviewed-by: 's avatarTim Van Patten <timvp@google.com>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
    • Inline depth/stencil clear if in middle of renderpass · 93eb633c
      Courtney Goeltzenleuchter authored 
      Some apps have a pattern where they clear the depth & stencil buffers
in the middle of the frame which causes the Vulkan backend to stop the
existing render pass and start a new one. This causes more loads &
stores of buffer contents than if we inline that clear with a draw.

Bug: b/159808300
Bug: angleproject:4695
Change-Id: I7a15af22f47a81051fa33fa19eaa123d8b66597c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2289945
Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarCharlie Lao <cclao@google.com>
    • Vulkan: fix RenderPassDesc::mColorAttachmentRange · 964c4089
      Shahbaz Youssefi authored 
      This variable tracks the index range of color attachments.  A previous
change (d8ce865b) made the range
inclusive so it can fit in 3 bits, but that's incorrect as it's no
longer possible to specify a range where no color attachments are
present.

This change partially reverts d8ce865b
to restore the previous semantics of
RenderPassDesc::mColorAttachmentRange.

Bug: chromium:1107884
Change-Id: I08da2568b5e63a48a672edd499a8b6653060eadb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2310578Reviewed-by: 's avatarShahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
  3. 21 Jul, 2020 18 commits
  5. 20 Jul, 2020 12 commits
  7. 18 Jul, 2020 1 commit
  9. 17 Jul, 2020 5 commits