kc3-lang/angle/src/libANGLE/renderer/vulkan/FramebufferVk.cpp

src/libANGLE/renderer/vulkan/FramebufferVk.cpp

Log

Author Commit Date CI Message
Mohan Maiya 6073af53 2021-03-08T11:21:31 Vulkan: Support EXT_sRGB_write_control Implement support for EXT_sRGB_write_control. This extension requires VK_KHR_image_format_list to be supported. The spec requires this functionality to work with glBlitFramebuffer as well but support for that will be added in a follow up change. As such, this extension is only exposed in non-conformant mode. Bug: angleproject:5075 Tests: SRGBFramebufferTest.*Vulkan* Change-Id: I59b38f6cd810a3d0d67ec29f4f19c25f65f70862 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2617243 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi e366e2c3 2021-02-27T01:00:02 Vulkan: Keep dynamic buffer's free list trimmed ContextVk's staging buffer never gets a chance to free its free buffer list. During application load time, a large amount of memory may be allocated from this buffer to stage texture updates and they would remain throughout the life of the application. This change ensures that the free buffer list doesn't grow unbounded. In the Manhattan trace, this saves >1GB of memory on Linux. There are now three policies for vk::DynamicBuffer: - Always reuse buffers: This is useful for dynamic buffers that make frequent small allocations, such as default uniforms, driver uniforms, default vertex attributes and UBO updates. - Never reuse buffers: This is for situations where the buffer is unlikely to be used after some initial usage, such as texture data upload or vertex format emulation (as the conversion result is cached, so it's never redone). - Limited reuse of buffers: For the staging buffer in the context which is shared by all immutable texture data uploads, it's useful to keep a limited number of buffers (1 in this change) to support future texture streaming while allowing a large number of buffers allocated in a burst to be discarded. Bug: angleproject:5690 Change-Id: Ic39ce61e6beb3165dbce4b668e1d3984a2b35986 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2725499 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Ian Elliott 6af0c03f 2021-02-25T18:15:21 Vulkan: Always write to swapchain alpha channel This fixes an issue with the "Ragnarok M: Eternal Love" game, which uses a GL_RGB8 format for its window, which is actually backed by a GL_RGBA8 format (a.k.a. "emulated alpha"). The game does no explicit clear per frame. Therefore, ANGLE selects a render pass loadOp=DONT_CARE, which leaves the alpha channel undefined (0.0 on a Pixel 4 XL). That causes SurfaceFlinger to show (blend or alternate vsyncs) what should have been covered up by the game (e.g. the Android launcher and live wallpaper). The solution is to prevent loadOp=DONT_CARE for emulated alpha. Test: ClearTest.ChangeFramebufferAttachmentFromRGBAtoRGB Test: dEQP-GLES2.functional.fbo.render.stencil_clear.tex2d_rgb_stencil_index8 Bug: b/180139027 Change-Id: Ied97b57c93d41326cb3294ff246691e09f316791 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2704949 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Mohan Maiya 550f2a3e 2021-02-24T09:49:42 Vulkan: Shader support for EXT_shader_framebuffer_fetch_non_coherent Translator can accept gl_LastFragData and 'inout' variable to gain access to framebuffer attachment data. The Vulkan translator replaces it with the SubpassInput type variable. Note that this works only for the noncoherent version of the extension. Bug: angleproject:5454 Test: *EXTShaderFramebufferFetchNoncoherent*.* Change-Id: I392f84ee3ad3eb9fbd09d0b7ff83731a9a3f33f6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2598060 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Shahbaz Youssefi 39d7fc18 2021-02-17T00:18:41 Vulkan: Don't break the render pass on dispatch calls The only reason a dispatch call may need to break the render pass implicitly is for read-after-writes where the write originates from the render pass but is not through a storage buffer/image. There are only two such scenrios possible: - Framebuffer attachment write -> texture sample - Transform feedback write -> ubo read All other uses of the buffers and textures that require breaking the render pass are handled by `glMemoryBarrier`. Bug: angleproject:5070 Change-Id: I92b50d69d8782097ee8ff477ac57da6209c326a1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2698998 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Mohan Maiya 907a3cee 2021-02-17T08:07:45 Vulkan: Add support for EXT_shader_framebuffer_fetch_non_coherent EXT_shader_framebuffer_fetch_non_coherent is implemented using subpass input attachments. The extension will be enabled in a follow up change that adds required changes to the Vulkan translator. Bug: angleproject:5454 Test: FramebufferFetchNonCoherentES31.*Vulkan Change-Id: Ic73c66a476c4a21db5269431166a198841f1dc0c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2598059 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 30622479 2021-02-16T12:33:40 Vulkan: Fix crash with deferred clears and MSRTT The following scenario was mishandled: - MSRTT draw with an unresolve operation (i.e. has two subpasses) - Deferred clear - Flush deferred clear with MSRTT framebuffer not needing unresolve (i.e. has one subpass) Bug: chromium:1178693 Change-Id: If3548e99897d698d61dfafbe9f86193723d06e5a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2697648 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 45a493ea 2021-02-05T13:48:48 Vulkan: Use a dirty bit to start the render pass Some dirty bits need to run before the render pass starts. An upcoming change for example needs to break the render pass when the program pipeline is changed while transform feedback is active. Another upcoming change may need to do the same based on a preceding glMemoryBarrier. This change adds a new dirty bit to start the render pass after some dirty bits have already been processed. Bug: angleproject:5528 Change-Id: I993c9efefed4c8fee268b218a8dd66a582d4e7cd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2678863 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 2e9706d8 2021-01-08T17:29:42 Vulkan: Use angle::FormatID instead of VkFormat. This change switches the internal enums we pass around from VkFormat to FormatID. The end goal of the refactor is to allow the Vulkan back-end to store packed tables indexed by FormatID. Because VkFormat has large gaps in its enum space we'd otherwise need to use unordered data structures like unordered_map. The change removes the redundant VkFormat storage from vk::Format and uses a new table query to return the VkFormat that 1:1 matches an angle::FormatID. We also include a reverse mapping for use with native Vulkan get functions for Android. Also moves sRGB conversion functions into renderer_utils. A couple sRGB formats that don't exist in GL are no longer handled by the sRGB conversion functions. These formats should be extremely rare. Bug: angleproject:5438 Change-Id: Id8b49773ca0c556f9f5a6a10fcf0d9762b93bbea Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2618204 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Stephan Hartmann d21d682d 2021-01-11T12:59:53 libstdc++: fix incomplete type for FramebufferCache libstdc++ does not allow incomplete type for T2 with std::pair<T1,T2> and fails with: .../../src/libANGLE/renderer/vulkan/vk_cache_utils.h:1570:64: required from here /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/include/g++-v9/bits/stl_pair.h:215:11: error: std::pair<_T1, _T2>::second has incomplete type 215 | _T2 second; /// @c second is a copy of the second object | ^~~~~~ https://chromium-review.googlesource.com/c/angle/angle/+/2580111 added class FramebufferCache with incomplete type in |mPayload| to vk::FramebufferHelper. Changing include order is not an option. However, FramebufferCache is only used in FramebufferVk and we can make it local there. Bug: chromium:957519 Change-Id: I5fbdca23adbb9f4aecc266988c02fb0d051504cb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2621473 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill e91097bf 2020-12-29T14:05:56 Vulkan: Clean up "actual"/"intended" naming. Clarifies that the GL internal format is an "intended" format and the Vulkan formats are "actual" formats. This makes all the format fields use the same consistent naming pattern. Bug: angleproject:5438 Change-Id: I935a49895109e9e06eae5ef98d5614dfd1128ff8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2605728 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 98b56e60 2020-12-12T16:28:21 Vulkan: Accumulate internal cache stats in renderer The CacheStats of all internal caches are accumulated by the renderer. In order to see the hit ratios of all caches, the following GN args must be enabled: is_debug = true angle_enable_perf_counter_output = true Bug: angleproject:5447 Test: Manual verification with angle_end2end_tests Change-Id: Iaca3249192e9e4e130d8291b7759c459d79b06ee Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2588430 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 46eaba7f 2020-12-12T10:31:26 Vulkan: Add support for internal cache hit and miss counts Add a CacheStats class that provides cache hit and miss bookkeeping. All internal caches make use of this class to keep track of its stats. This provides a means to profile cache hit ratios a.k.a Vulkan object reuse for any application. Bug: angleproject:5447 Test: Manual verification with angle_end2end_tests Change-Id: I44eeb0c2b9b291ec1cdd156fb2be4a5fe80d2848 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2580111 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya da8c2261 2020-12-12T16:39:55 Vulkan: Enable FramebufferVk cache on Apple This effectively reverts ff60aba. The crash no longer occurs on Apple. Bug: angleproject:4442 Change-Id: I4aa745c80a482eb99311f3810e34124afe950cfe Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2588429 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Shahbaz Youssefi 56330564 2020-12-10T00:46:04 Vulkan: Support layered framebuffers This feature is introduced by geometry shaders, where all the layers of a texture can be attached to a framebuffer. The geometry shader would use gl_Layer to decide which layer the primitive should be rendered to. Bug: angleproject:3571 Change-Id: Ib2ae8e227b226295f9e2f62f6b230839070bc95c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2582711 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 0d2de6f0 2020-12-03T04:29:02 Vulkan: Fix precision issue in blit math Bug: chromium:1154759 Change-Id: If31ef7ebecdfa2a0cba91e917870ea0bdfd9b9db Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2570464 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 46107d3e 2020-11-18T22:03:22 Vulkan: Delay defining D/S content to endRenderPass Take the following situation: 1. Start RP with D/S undefined: loadOp = DONT_CARE, storeOp = STORE * At this point, onDepthStencilWrite calls image->onWrite, setting depth/stencil contents defined. 2. At endRP, observe depth/stencil is not used: storeOp = DONT_CARE 3. Start another RP with D/S: loadOp = LOAD, storeOp = STORE Because the call to image->onWrite was done at startRP, the contents of the depth/stencil image is marked as defined, and the next render pass is loading these data. This change moves image->onWrite to endRenderPass, and only calls it if storeOp = STORE, taking advantage of all the opportunistic optimizations that try to set storeOp to another value. Bug: angleproject:4836 Change-Id: I9858e5caa6b1f67f841a5c6356e66927356ef469 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2548319 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 86d7e4d8 2020-11-10T15:55:34 Vulkan: Support texture buffers Texture buffers are placed in the same descriptor set with the rest of the textures. However, the different code paths that handle textures have special cases for texture buffers as they create a different descriptor type (texel buffer instead of combined image sampler). Image view serials are used to track the buffer view serials as well so the texture descriptor cache can handle texture buffers as well. This CL is missing storage texel buffer support. Bug: angleproject:3573 Change-Id: Iff80ca22ff9b9957a0c9a3c7aaada1fa54b24ec8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2532653 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Amy Liu b10a0dfc 2020-11-12T14:51:05 Fix flip info of colorBlit with pre-rotation. Get wrong colorBlit results on android if there is flip operation added by glBlitFramebuffer API. Fix the implementation and add related end2end tests. Bug: angleproject:5044 Change-Id: I797f8858b3943b5effe27261e954ca1405960ef0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2534210 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 9e7f08fc 2020-11-06T16:55:51 Vulkan: Fix incorrect reordering of barriers Take the following situation, a simple copy from image to buffer: ANGLE_TRY(contextVk->onBufferTransferWrite(buffer)); ANGLE_TRY(contextVk->onImageTransferRead(aspectFlags, image)); CommandBuffer &commandBuffer = contextVk->getOutsideRenderPassCommandBuffer(); commandBuffer.copyImageToBuffer(imageHandle, layout, bufferHandle, 1, regions); Both `onBufferTransferWrite` and `onImageTransferRead` may flush either the outsideRP or insideRP command buffers. If buffer is not previously used, but image is used: - onBufferTransferWrite: buffer usage is recorded in outsideRP1 - onImageTransferREad: outsiderRP1 is flushed, outsideRP2 is started - copyImageToBuffer: recorded on outsideRP2, but buffer usage not recorded there - A following command that uses the buffer and requires barrier doesn't close outsideRP2 as it believes it was not used there Bug: angleproject:5319 Change-Id: Ib8994083fbc21969a538cda3784adee57b089415 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2523388 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 3dfaeeb0 2020-10-30T16:57:44 Vulkan: Don't flush deferred clears on READ framebuffer sync Deferred clears are not collected when syncing the READ framebuffer. Prior to this change, we had in FramebufferVk::syncState: if (READ && deferredClears.any()) { flushDeferredClears(); } However, this is impossible / unnecessary: - Every operation whose syncState (for the DRAW framebuffer) collects deferred clears will flush the deferred clears. In fact, it's an error for the next operation's syncState to encounter pre-existing deferred clears. - The READ framebuffer is synced before the DRAW framebuffer. This makes it impossible for there to be deferred clears when READ is synced. It may be necessary to swap the order in which the READ and DRAW framebuffers are synced. See http://anglebug.com/5266. In that case, if the READ and DRAW framebuffers are identical: - The DRAW framebuffer's sync will collect deferred clears. The READ framebuffer's sync will see deferred clears, but it must not flush them! Bug: angleproject:4988 Change-Id: I179002d739608ccb8bda95d4379dc6d54e2bf4bb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511372 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 2d964a47 2020-10-30T16:46:30 Vulkan: Defer clears even if following command is scissored Take the following scenario: 1. glClear 2. glScissor(half of framebuffer) 3. glDrawArrays The clear in step 1 is deferred. When FramebufferVk::syncState is called in step 3, the deferred clear was applied using vkCmdClearColorImage because the draw call is scissored. This causes loadOp=LOAD to be used after the clear because the render pass is started too small (the same size as the scissor). This change makes scissored operations also take advantage of loadOp=LOAD with deferred clears. A number of changes are made to this effect: - FramebufferVk::syncState no longer limits collecting deferred clears to no-scissor. - FramebufferVk::startNewRenderPass automatically expands the render area to full size if it's clearing any attachment. - A number of bugs are fixed where FramebufferVk::flushDeferredClears is called with the scissor area. Instead, flushDeferredClears now unconditionally uses the complete render area. Note that these bugs didn't have symptoms as "scissor" and "deferred clears" were mutually exclusive. Bug: angleproject:4988 Change-Id: I24fc3d88bf9c8998869b36c863692d0f0acce994 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511371 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi a0e91016 2020-10-30T10:01:36 Vulkan: Don't break the render pass on scissor change Prior to this change, the render area was decided when the render pass was started, and remained fixed. If a small scissor was initially used, this created a render pass with a small area. If then the scissor region was expanded, the render pass was broken. This change instead expands the render area on scissor change to avoid breaking the render pass. If glInvalidateSubFramebuffer previously successfully resulted in storeOp=DONT_CARE, this optimization may need to undo that. As a result, the invalidate area is stored in the render pass and if the render area grows beyond that, invalidate is undone. Bug: angleproject:4988 Change-Id: I4e8039dec53a95a193a97cb40db3f71e397568d6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2508983 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 265c5fa9 2020-11-02T21:50:25 Vulkan: Fix scissor update in FramebufferVk::syncState A previous change [1] made FramebufferVk::syncState update scissor and rasterization samples only when the DRAW framebuffer is synced. This is incorrect as the READ framebuffer is synced before the DRAW framebuffer, and if the two are the same, the latter is discarded. Very few functions sync both READ and DRAW framebuffers when they are identical. A test is tailored to expose this bug. [1]: https://chromium-review.googlesource.com/c/angle/angle/+/2510013 Bug: angleproject:4988 Change-Id: I6123ac18dded938171bc90a04d4d81f1b42a1694 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2515742 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 8afe3f17 2020-11-03T10:55:31 Vulkan: Fix use of uninitialized data in staged clears When depth/stencil data are staged, only the depthStencil field of VkClearValue is initialized. However, when comparing staged clears, memcmp is used which also compares the extra bytes in the aliasing color field. Bug: chromium:1144491 Change-Id: Ic384ba792e9fd199d8e9c3e534ccdc6ea65ee9b8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2517244 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 7dc92430 2020-10-30T13:05:05 Noop clear of non-existing attachments. Bug: angleproject:4988 Change-Id: Ib6ff9756ec7ae5aa2b11f4d12932829fe05656d6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511369 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 42e10d3e 2020-10-30T16:36:45 Noop empty-scissor clears Bug: angleproject:4988 Change-Id: I64909292927e20c65141302c9bf5e7ef09af84b7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511370 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 57f7c9b5 2020-10-29T16:31:46 Vulkan: Fix prerotation bug with glInvalidateSubFramebuffer The area passed to FramebufferVk::invalidateSub is not rotated, but was being compared with the rotated framebuffer dimensions / render area. Bug: angleproject:5264 Change-Id: I2de181bf77ad650418b757a3848395bbdab13d8a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2508978 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill 97843bda 2020-10-30T17:03:36 Vulkan: Fix EGL Surface robust init. The error here was related to using a single cache variable for the robust init setting for all the surfaces in a DisplayVk. Fix this by passing down the robust init setting from the SurfaceVk to image init. Bug: angleproject:5274 Change-Id: I9bc9c20990268d1d5166411fb53f8f2593fd1971 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2510694 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 9c66a092 2020-10-30T09:56:19 Vulkan: Update scissor only in DRAW framebuffer's syncState Bug: angleproject:4988 Change-Id: I16f9268cdc221c84f962bbb9bd06ef5b19a6ac05 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2510013 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 8f36b846 2020-10-29T15:13:55 Vulkan: Optimize glFramebufferSubInvalidate If glFramebufferSubInvalidate() is called with an area that covers the whole framebuffer, behave as if glFramebufferInvalidate() is called. This allows deferred clears to be removed for example, and attachment contents to be marked undefined. Bug: angleproject:4988 Change-Id: Iff3f291ea6c07abccc2740174d0451b432ac5da8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2508977 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Alexey Knyazev 1c7f0284 2020-10-21T01:40:08 Vulkan: Fix invalid clamping of ES3 clear stencil values Added 3 new end2end tests Bug: angleproject:5202 Change-Id: I95f9ffd989105f5bd3283676d6fa46e904503369 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2488481 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Shahbaz Youssefi c55cd6b4 2020-10-14T23:06:27 Vulkan: Remove dead path in clear If the clear is not mid render pass, clearWithLoadOp was used to either: - modify the current render pass loadOps, assuming no rendering has been done, or - defer the clears by staging them in the attachment images. The former path however is dead code. It's impossible to start the render pass without recording any commands. In other words, if the render pass has already started, the clear must be mid RP. Bug: angleproject:4836 Change-Id: Idb1cb37b8a0e56b897ac69cf435f9a52be4bd2f4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2473764 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Tim Van Patten 16102e8b 2020-10-17T01:15:05 Reland "Vulkan: Fold deferred clears into current clears" This reverts commit 37c400146e59f718b516eb58e16fa53c8a88bf21. Reason for revert: Need to clear the package cache when bisecting. Original change's description: > Revert "Vulkan: Fold deferred clears into current clears" > > This reverts commit e416c92a81c9ef01d633ec5c05e81c2551b6c5d6. > > Reason for revert: Reverted parent: > https://chromium-review.googlesource.com/c/angle/angle/+/2481612 > > Original change's description: > > Vulkan: Fold deferred clears into current clears > > > > If there are clears prior to a glClear() call, those clears were > > flushed (starting a new render pass) and then the clear call's clears > > would be applied (essentially modifying the loadOps of said render > > pass). > > > > The main downside of the above is that the current glClear() clears > > don't get a chance to be deferred. This was observed in Chrome which > > clears an attachment with an emulated format, then switches > > framebuffers. > > > > Additionally, if the render pass had already been started, the deferred > > clears could have become inlined instead of breaking the render pass. > > Although, it's unlikely for there to be deferred clears when the render > > pass is already open. > > > > This change first identifies which clears need to go through the draw > > path (scissored, masked or as workaround for driver bug). It merges the > > rest of the clears (that don't need the draw path) with the deferred > > clears. It then checks deferred clears and applies them by either: > > > > - vkCmdClearAttachments if mid RP > > - Start a new render pass and use loadOps, if any draw-based clear needs > > to follow. > > - Modify current RP loadOps / defer the clear > > > > Afterwards, the draw-based clears are applied. > > > > Bug: angleproject:4836 > > Change-Id: Id4992c78983b199734508c9d4bb18ed3195c91ec > > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2455167 > > Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> > > Reviewed-by: Jamie Madill <jmadill@chromium.org> > > Reviewed-by: Charlie Lao <cclao@google.com> > > TBR=syoussefi@chromium.org,jmadill@chromium.org,cclao@google.com > > Change-Id: I85733b3594409df9b96e3d5b34933522c97c42cf > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: angleproject:4836 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2481613 > Reviewed-by: Tim Van Patten <timvp@google.com> > Commit-Queue: Tim Van Patten <timvp@google.com> TBR=timvp@google.com,syoussefi@chromium.org,jmadill@chromium.org,cclao@google.com # Not skipping CQ checks because this is a reland. Bug: angleproject:4836 Change-Id: I702cd510f39ee46feab27d4efbf61ae5da10d4e2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2481856 Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 37c40014 2020-10-16T22:19:20 Revert "Vulkan: Fold deferred clears into current clears" This reverts commit e416c92a81c9ef01d633ec5c05e81c2551b6c5d6. Reason for revert: Reverted parent: https://chromium-review.googlesource.com/c/angle/angle/+/2481612 Original change's description: > Vulkan: Fold deferred clears into current clears > > If there are clears prior to a glClear() call, those clears were > flushed (starting a new render pass) and then the clear call's clears > would be applied (essentially modifying the loadOps of said render > pass). > > The main downside of the above is that the current glClear() clears > don't get a chance to be deferred. This was observed in Chrome which > clears an attachment with an emulated format, then switches > framebuffers. > > Additionally, if the render pass had already been started, the deferred > clears could have become inlined instead of breaking the render pass. > Although, it's unlikely for there to be deferred clears when the render > pass is already open. > > This change first identifies which clears need to go through the draw > path (scissored, masked or as workaround for driver bug). It merges the > rest of the clears (that don't need the draw path) with the deferred > clears. It then checks deferred clears and applies them by either: > > - vkCmdClearAttachments if mid RP > - Start a new render pass and use loadOps, if any draw-based clear needs > to follow. > - Modify current RP loadOps / defer the clear > > Afterwards, the draw-based clears are applied. > > Bug: angleproject:4836 > Change-Id: Id4992c78983b199734508c9d4bb18ed3195c91ec > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2455167 > Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Charlie Lao <cclao@google.com> TBR=syoussefi@chromium.org,jmadill@chromium.org,cclao@google.com Change-Id: I85733b3594409df9b96e3d5b34933522c97c42cf No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: angleproject:4836 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2481613 Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi e416c92a 2020-10-06T23:29:02 Vulkan: Fold deferred clears into current clears If there are clears prior to a glClear() call, those clears were flushed (starting a new render pass) and then the clear call's clears would be applied (essentially modifying the loadOps of said render pass). The main downside of the above is that the current glClear() clears don't get a chance to be deferred. This was observed in Chrome which clears an attachment with an emulated format, then switches framebuffers. Additionally, if the render pass had already been started, the deferred clears could have become inlined instead of breaking the render pass. Although, it's unlikely for there to be deferred clears when the render pass is already open. This change first identifies which clears need to go through the draw path (scissored, masked or as workaround for driver bug). It merges the rest of the clears (that don't need the draw path) with the deferred clears. It then checks deferred clears and applies them by either: - vkCmdClearAttachments if mid RP - Start a new render pass and use loadOps, if any draw-based clear needs to follow. - Modify current RP loadOps / defer the clear Afterwards, the draw-based clears are applied. Bug: angleproject:4836 Change-Id: Id4992c78983b199734508c9d4bb18ed3195c91ec Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2455167 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 39b5e771 2020-10-09T11:06:10 Vulkan: Fix vector size issue with clearWithCommand gl::DrawBuffersVector was used to hold the clear values, but that didn't have enough space for depth/stencil clear values if MAX draw buffers where used and cleared. The added test in this change exposes the vkCmdClearAttachment Qualcomm bug (previously presumed to affect color clears only) with depth/stencil buffers, so the workaround is expanded to avoid vkCmdClearAttachment entirely. Bug: b/159808300 Change-Id: I27c58d9b534bce0bdd27cc53fc64e139f1363c1a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2455166 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Shahbaz Youssefi df8f71d1 2020-10-09T15:27:28 Vulkan: Don't break the render pass on scissored clears clearImmediatelyWithRenderPassOp is removed and the draw path is used for the scissor. That path was added to avoid creating a large number of graphics pipelines due to the scissor state. This is now done by using dynamic state for scissor in the draw path for clear. Running the following dEQP tests without and with dynamic state for scissor: dEQP-GLES3.functional.fragment_ops.depth_stencil.stencil_ops.* the number of graphics pipelines is reduced from 95392 to 16. Bug: angleproject:4617 Bug: angleproject:4836 Change-Id: Ib373d8cd23ca2b67e6fd26aa2a1103f281f7e473 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2463985 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Charlie Lao df6b7298 2020-10-12T13:39:09 Vulkan: Use StoreOp_None_QCOM for read only depth stencil buffer For read only depth stencil buffers, there is no need to store depth or stencil value. But we can not use DontCare for storeOp because vulkan core spec says DontCare indicates data is undefined after this. VK_QCOM_render_pass_store_ops extension introduces a new store op that will leave data defined but skip the store. This CL utilize this if the extension is available. Bug: angleproject:5055 Change-Id: I104f3d01eb342a2d0cc900f342430e901bde1bff Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462604 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 68bd685a 2020-10-10T22:58:41 Reland: "4 Vulkan content defined CLs." Reland "Vulkan: Avoid content restore by detecting no-op stencil" This relands commit 243d0f899e443cd931c78aba7489382dff79edbb. Reland "Vulkan: Restore at the end of RP if write-after-invalidate" This relands commit e5d52ac3b9a00656acdd912ee8cd62dd14784075. Reland "Vulkan: Invalidate/restore depth/stencil separately." This relands commit 61fa0878964a796f6d3b3c13bc3a3849403ecdbd. Reland "Vulkan: Move content-defined tracking to ImageHelper" This relands commit 2392e6b34c0ddfbfd7b4c3cb67323ba463e11a57. Reason for revert: Caused crashes in Fuchsia x64 and on ARM. Reland fixes content defined for external images. Original CL message: Content-defined tracking was done in render targets prior to this change. This had multiple drawbacks: - When a framebuffer attachment is changed (including the first time it's set), it's unknown whether the contents of the attachment is defined. - Invalidate takes effect at the end of render pass, at which point the render target objects may be gone. Attachment ImageHelpers are however correctly tracked. This change moves content-defined tracking to the ImageHelper itself, and tracks it per subresource. ImageHelper::onWrite() now receives the subresource that is being written, and marks it as having defined content. A future optimization can make use of this change to ImageHelper::onWrite to track "dirty" subresources. This can lead to the removal of unnecessary barriers when same-kind writes are done on different subresources of the image. See http://anglebug.com/3347#c15 Bug: b/167275320 Bug: angleproject:4836 Bug: angleproject:5159 Change-Id: If5c1ae7152657fd7c94db7d55bea4fb9ddf835ba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2464825 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill d6b1c17b 2020-10-10T14:29:15 Revert 4 Vulkan content defined CLs. Revert "Vulkan: Avoid content restore by detecting no-op stencil" This reverts commit 243d0f899e443cd931c78aba7489382dff79edbb. Revert "Vulkan: Restore at the end of RP if write-after-invalidate" This reverts commit e5d52ac3b9a00656acdd912ee8cd62dd14784075. Revert "Vulkan: Invalidate/restore depth/stencil separately." This reverts commit 61fa0878964a796f6d3b3c13bc3a3849403ecdbd. Revert "Vulkan: Move content-defined tracking to ImageHelper" This reverts commit 2392e6b34c0ddfbfd7b4c3cb67323ba463e11a57. Causes crashes in Fuchsia x64 and on ARM. Original CL message: Content-defined tracking was done in render targets prior to this change. This had multiple drawbacks: - When a framebuffer attachment is changed (including the first time it's set), it's unknown whether the contents of the attachment is defined. - Invalidate takes effect at the end of render pass, at which point the render target objects may be gone. Attachment ImageHelpers are however correctly tracked. This change moves content-defined tracking to the ImageHelper itself, and tracks it per subresource. ImageHelper::onWrite() now receives the subresource that is being written, and marks it as having defined content. A future optimization can make use of this change to ImageHelper::onWrite to track "dirty" subresources. This can lead to the removal of unnecessary barriers when same-kind writes are done on different subresources of the image. See http://anglebug.com/3347#c15 Bug: b/167275320 Bug: angleproject:4836 Bug: angleproject:5159 Change-Id: I93d9dfe973caa7ce70aefa46b5b7d04a8637efb3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2464822 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 6c1c3bd9 2020-10-09T11:46:04 Vulkan: Clear depth by shader if depthClamp not supported This will avoid breaking the render pass when clearing depth through clearWithDraw if the depthClamp Vulkan feature is not present. Bug: angleproject:4836 Change-Id: I845fd5074dd95f6896da89f9e119ebc5000a5688 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462719 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi e5d52ac3 2020-10-08T14:26:22 Vulkan: Restore at the end of RP if write-after-invalidate If a depth/stencil attachment is invalidated, but subsequently drawn to in the same render pass, undo the invalidate when the render pass is closed. Adapted from https://chromium-review.googlesource.com/c/angle/angle/+/2386478. Bug: b/167275320 Bug: angleproject:4836 Change-Id: I17a35bfd692ddc403ceaa6ec44b5c4f16ff9eed6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2461464 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi f8070feb 2020-10-09T11:03:29 Vulkan: Use depthClamp to clear depth where available This will avoid breaking render pass if clearing depth in clearWithDraw. Bug: angleproject:4836 Change-Id: I50242d1115efc91059923143f6ae5fd25fb3d36f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462717 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 61fa0878 2020-10-08T11:35:48 Vulkan: Invalidate/restore depth/stencil separately. Depth/stencil content defined is already tracked separately in the ImageHelper. This change exposes this tracking from RenderTargetVk. Bug: b/167275320 Bug: angleproject:4836 Change-Id: Ie6520e7a4ab557eb233c60c6ab0d4a8f8f098bf6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462039 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Tim Van Patten a3d5a6e3 2020-10-07T15:03:40 Vulkan: Call onColorDraw in resolveColorWithSubpass We are currently calling onImageRenderPassWrite() on the read render target within resolveColorWithSubpass(). We need to instead call onColorDraw() on the draw render target, since that's what's actually being written. Bug: b/159903491 Test: CQ Change-Id: I577381d91228e132950455d2e872fbb9b066d0c8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2458850 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 2392e6b3 2020-10-07T23:59:43 Vulkan: Move content-defined tracking to ImageHelper Content-defined tracking was done in render targets prior to this change. This had multiple drawbacks: - When a framebuffer attachment is changed (including the first time it's set), it's unknown whether the contents of the attachment is defined. - Invalidate takes effect at the end of render pass, at which point the render target objects may be gone. Attachment ImageHelpers are however correctly tracked. This change moves content-defined tracking to the ImageHelper itself, and tracks it per subresource. ImageHelper::onWrite() now receives the subresource that is being written, and marks it as having defined content. A future optimization can make use of this change to ImageHelper::onWrite to track "dirty" subresources. This can lead to the removal of unnecessary barriers when same-kind writes are done on different subresources of the image. See http://anglebug.com/3347#c15 Bug: b/167275320 Bug: angleproject:4836 Change-Id: Iabd1dace4eae9eb379453a9eb7ec6eafc9db1aef Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462036 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi 1a87f1f0 2020-10-06T17:15:34 Add a test for deferred clears and 0-sized scissor clears The Vulkan backend no-ops such clears before flushing deferred clears. Deferred clears are actually not gathered when doing a scissored clear, so this is not an issue. An ASSERT is added along with a regression test. Bug: angleproject:4836 Change-Id: I5ea5bab499ced41e13023ffb6b821e3caefb9ab2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2453466 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 22ed1e59 2020-10-05T17:59:27 Vulkan: Remove depth stencil access out of RenderPassDesc Vulkan spec says that image layout is not counted toward render pass compatibility: "Two render passes are compatible if their corresponding color, input, resolve, and depth/stencil attachment references are compatible and if they are otherwise identical except for: Initial and final image layout in attachment descriptions Image layout in attachment references" This CL removes the depth stencil access mode information out of RenderPassDesc structure. It is essentially partially reverted the change from crrev.com/c/2354280 Bug: b/170134600 Change-Id: Iada4d89c3249489b47db3046952e7cb10f252891 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2451597 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Alexey Knyazev d5fa6ea9 2020-04-29T04:13:54 Vulkan: Implement OES_draw_buffers_indexed Bug: angleproject:4394 Change-Id: I7db9c695c233b2daf740acc654b1b2e546a8b681 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2172739 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Charlie Lao 77e3d0ae 2020-09-25T14:12:04 Vulkan: Defer the depthStencil buffer layout change to endRenderPass Depth stencil layout may change while we build the render pass, depending on the read/write access been made. Right now we are always inserting a layout change barrier at the start of render pass. Later on when the read/write property changes, we insert another layout change barrier. Similarly, we maintain the attachmentOps and RenderPassDesc::mPackedColorAttachmentRangeAndDSAccess as we changes read/write access. This makes code quite commplicated. This CL moves mReadOnlyDepthStencilMode from FramebufferVK to CommandBufferHelper object and we only maintain that boolean while we updating the read/write access. Then at the end of render pass or when depthStencil image is deleted, we update attachmentOps and mRenderPassDesc and layout transition all at once and only done once. This simplifies the read only depth stencil mode implementation a lot. Bug: b/168953278 Change-Id: Ie263b4526c82a9858e5d1f141ea58f499187a3ca Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2432075 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Trevor David Black e815afbf 2020-09-07T22:09:22 First pass at increasing inclusivity Link to the inclusivity rules https://source.android.com/setup/contribute/respectful-code Bug: b/162834212 Bug: chromium:1097198 Change-Id: Ied5a9e3879d72bff3f77ea6fcda9b82f30c32c2f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2396737 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Trevor Black <vantablack@google.com>
Charlie Lao c6dc9d73 2020-09-19T20:09:34 Vulkan: Add a test and fix the bug with draw/invalidate/clear This adds a test that does draw with depth enabled, then disable depth test but with depth mask still enabled. Then invalidate framebuffer and followed by a clear. That clear will go down clearWithCommand path and should still work and data stored. Bug: b/169590459 Change-Id: I6dd30d6a1e12ad7820d98fe79445c336cfa3a643 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2422081 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 2f3d18f2 2020-10-01T05:58:44 Vulkan: Fix unresolve disagreement between FB and RP FramebufferVk::updateRenderPass reset the render pass description, but not the framebuffer description. This caused a disagreement between the two regarding which attachments need to be unresolved. Later, FramebufferVk::startNewRenderPass could miscalculate whether a new framebuffer needs to be generated based on changes in unresolve attachments. For example: - say in the first render pass color needs to be unresolved. Both RP and FB desc would remember this (each being keys for their respective caches). - A following operation triggers syncState such that FB desc changes (for example rebind of attachment), which cleared RP desc but not FB desc's unresolve attachment state. - If the next render pass does not require an unresolve (for example due to a clear or invalidate), then the framebuffer is not recreated because according to RP desc at the start and end of FramebufferVk::startNewRenderPass there has been no change in unresolve mask. * At start there's no unresolve because of syncState clearing it. * At end there's no unresolve because there's no need for unresolve. - In the end, the framebuffer used for the first render pass would be used for the second render pass as well. Note that: * The first render pass included an unresolve, i.e. two subpasses. * The second render pass requires one subpass according to its RP desc. It's quite easy to accidentally have the framebuffer correctly recreated (based on the reset RP desc) before FramebufferVk::startNewRenderPass. Note that since syncState has called updateRenderPass, FB desc has necessarily changed, and mFramebuffer is nullptr, so any call to FramebufferVk::getFramebuffer would recreate the framebuffer. Both clear and invalidate call FramebufferVk::getFramebuffer. The issue is reproducible in situations where clear/invalidate has been called before the framebuffer is modified, and then draw is issued after the modification. An ASSERT is added to catch discrepencies between RP desc and FB desc to catch bugs even when the issue doesn't manifest itself as a VVL error. Bug: angleproject:4836 Change-Id: I8a0d116402a6c298377d03e0908baa942019ccd5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2442379 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 463e02e6 2020-09-29T14:46:46 Vulkan: Constants for unpacked D/S attachment indices kClearValueDepth/StencilIndex is renamed and repurposed in other places where depth and stencil are placed at indices MAX_DRAW_BUFFERS and MAX_DRAW_BUFFERS+1. Bug: angleproject:4836 Change-Id: Idaeff5017d944d786a5f388c4f1ce3a4e3fe9b7d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2437505 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 43163491 2020-09-22T11:45:06 Vulkan: Unresolve depth/stencil MSRTT attachments Using the same shader that unresolves color, this change allows depth/stencil to be unresolved as well. In turn, this allows the depth and stencil loadOp/storeOp of the implicit multisampled image associated with a multisampled-render-to-texture renderbuffer to be set to DONT_CARE. Stencil unresolve depends on VK_EXT_shader_stencil_export. In the absence of this extension, the stencil aspect is not unresolved and must continue to use loadOp=LOAD and storeOp=STORE. This is not ideal, but the expected use-case of depth/stencil MSRTT renderbuffers is that they get invalidated, so that load and store wouldn't happen in practice. Bug: angleproject:4836 Change-Id: I9939d1e15e10fa8ed285acdd6fe6edb42c59054f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2427049 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Tim Van Patten f57b00f1 2020-09-28T09:53:52 Vulkan: Don't modify mReadOnlyDepthStencilMode in syncState() We're currently looking for any deferred clears before disabling read-only depth/stencil mode in FramebufferVk::syncState(). This CL removes that checking, since read-only D/S mode is configured at the start of a render pass, so it doesn't need to be updated again as part of changing framebuffers. Bug: b/168953278 Test: CQ Change-Id: I386114640f2b763c964d5ef0c18b1d31449a6f1f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2435497 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Charlie Lao ae24f28a 2020-09-22T17:33:32 Vulkan: Move mReadOnlyDepth out of FramebufferDesc The depth read only or not should not affect VkFramebuffer creation. RenderPasses with just depthstencil layout differences are considered compatible. This CL moves this out of FramebufferDesc into FramebufferVk. Bug: b/168953278 Change-Id: I5bd05b262b7b3b0dc70f9fb8fc4a3db5e7082916 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2425032 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Charlie Lao d2d9e682 2020-09-15T16:06:42 Vulkan: Use DepthStencilReadOnly when it is read only. We are tracking depth and stencil read or write during the renderpass. We can use that to switch to DepthStencilReadOnly layout if both depth and stencil are not writing. This allows drivers to optimize out the storeOp for the renderpass. Bug: b/168953278 Change-Id: Id82e06b4bae1ae8c83d880bb5e58accfa61f8191 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2411336 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi a3b16c6b 2020-08-28T16:14:30 Vulkan: Workaround vkCmdClearAttachment bug on Pixel Adds a workaround to use draw calls to clear color instead of vkCmdClearAttachment when the clear happens in the middle of render pass. On Pixel phones, vkCmdClearAttachment races with the previous draw calls in the render pass. Bug: b/166809097 Change-Id: I8c96b87793da191757635658ad4ee2c3a7875aca Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2382416 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Tim Van Patten 001c7e8c 2020-09-21T13:25:46 Vulkan: Link PPO during draw validation From the OpenGL ES 3.1 spec: 11.1.3.11 Validation It is not always possible to determine at link time if a program object can execute successfully, given that LinkProgram can not know the state of the remainder of the pipeline. Therefore validation is done when the first rendering command which triggers shader invocations is issued, to determine if the set of active program objects can be executed. For draws, this CL moves the PPO link operation to ValidateDrawStates() to generate PPO link failures within ANGLE's validation layer, so we fail any rendering commands during command validation. For dispatch, PPOs are linked during Context::prepareForDispatch(), where the PPO is converted from draw to compute, since that conversion requires a re-link. This re-link shouldn't fail due to errors that would have been caught during validation, since the compute shader must have successfully linked before it can be included in the PPO in the first place. We don't re-link when converting back to draw, since it's possible there are validation errors (which we want to catch during validation of the next rendering command). Bug: angleproject:5064 Test: dEQP.GLES31/functional_separate_shader_validation_es31_* Test: ContextNoErrorTest31.DrawWithPPO Test: ProgramPipelineTest31.VerifyPpoLinkErrorSignalledCorrectly Change-Id: Ibb249e893c007a83cc6b813f848a660bfa34ecb0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2422375 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Charlie Lao d59bccb5 2020-09-23T10:20:35 Vulkan: updateRenderPassDesc may lose color attachment data FramebufferVk::updateRenderPassDesc() is resetting entire mRenderPassDesc, which may lose color unresolve attachments. This CL makes sure that when we toggle depth stencil buffer's read/write access, we do not reset the whole mRenderPassDesc. Instead we only update the depth stencil attachment's access. Bug: b/168953278 Change-Id: Ia9df2d8ac81ebf2da8a360ba1293faf6c14b2738 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2426468 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi a76b6836 2020-09-17T22:40:42 Vulkan: Support MSRTT depth/stencil resolve VK_KHR_depth_stencil_resolve is used by this change to resolve depth/stencil multisampled-render-to-texture renderbuffers. This extension is not widely supported yet. If it's not present, the depth/stencil resolve operation is silently ignored and the renderbuffer acts as a normal multisampled one. This is not correct, but our primary user (Chrome), and most applications don't care for the resolved depth/stencil data. In fact, it's recommended for the depth/stencil attachment to be invalidated after rendering. Exposing EXT_multisampled_render_to_texture even in the absence of depth/stencil resolve allows the majority of the applications to still take advantage of MSRTT color attachments. Bug: angleproject:4836 Change-Id: I6ba4187344a0c9330d2c77bdc5e2c6fc5483c299 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2417645 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Mohan Maiya 9e2953c2 2020-09-23T07:57:22 Vulkan: Enable OES_texture_storage_multisample_2d_array The implementation for OES_texture_storage_multisample_2d_array already exists. This patch just enables the appropriate capability flag only if the underlying Vulkan ICD supports standardSampleLocations Bug: angleproject:3583 Tests: angle_end2end_tests --gtest_filter="*TextureMultisampleArrayWebGLTest*Vulkan" dEQP-GLES31.functional.state_query.internal_format.texture_2d_multisample_array.* dEQP-GLES31.functional.state_query.texture_level.texture_2d_multisample_array.* Change-Id: I2ea89041d9aa8c7d94c9ba732f12528c809807ac Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2416979 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Shahbaz Youssefi f39e0f01 2020-09-07T23:07:37 Vulkan: Use subpass to unresolve render-to-texture attachments GL_EXT_multisampled_render_to_texture allows singlesampled textures to be used with multisampled framebuffers in such a way that the final resolve operation is automatically done. In Vulkan terminology, the render-to-texture GL attachment is used as a Vulkan subpass resolve attachment with an implicit (ideally-)lazy-memory multisampled image as the color attachment. This extension expects that if the texture is drawn to after the automatic resolve, the implicit multisampled image would take its fragment colors from the singlesampled image. In other words, the opposite of a resolve operation should be automatically performed at the start of the render pass. This change refers to this operation as "unresolve". The goal of this extension is to allow tiling GPUs to always keep multisampled data on tile memory and only ever load/store singlesampled data. The latter is achieved by using a subpass resolve attachment and setting storeOp of the multisampled color attachment to DONT_CARE. This change achieves the former by using an initial subpass that uses the resolve attachment as input attachment, draws into the multisampled color attachment and sets loadOp of said attachment to DONT_CARE. Bug: angleproject:4881 Change-Id: I99f410530365963567c77a7d62fc9db1500e5e3e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2397206 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi edc0d2ee 2020-09-15T16:02:05 Vulkan: Disallow loadOp=LOAD for MSRTT depth/stencil textures EXT_multisampled_render_buffer2 specifies that depth/stencil textures are expected to be in a perpetual state of invalidated, except during rendering. This change makes sure that they never use loadOp=LOAD. Additionally fixes a bug where clears applied to MSRTT depth/stencil textures didn't take effect because they were applied to the multisampled image (since the resolved image was not given to the render target). Bug: angleproject:4836 Bug: angleproject:5063 Change-Id: I4506f4de415dca6c222111a1ae62017d2fb1e2b1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2412848 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 5f8af83f 2020-09-17T11:06:08 Vulkan: Add perf warning for mid-RP clear Bug: angleproject:3461 Change-Id: Id80ccc81db3cb66438b6b5e6d504eda613f481d1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2416244 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Ian Elliott 1c79e9ea 2020-09-17T09:50:46 Vulkan: Delay vkAcquireNextImageKHR till later Currently, ANGLE calls vkAcquireNextImageKHR() immediately after calling vkQueuePresentKHR(), which can cause the process to stall (even with multi-threading). Delay it until it is absoluately needed. Test: angle_end2end_tests --gtest_filter=*EGLPreRotationSurfaceTest*/* Test: angle_white_box_tests --gtest_filter=VulkanPerformanceCounterTest.*Invalidate*/* Test: angle_deqp_egl_tests --gtest_filter=dEQP.EGL/functional_query_context_get_current_display_rgba8888_window* --use-angle=vulkan Test: angle_perftests --gtest_filter=GenerateMipmapBenchmark.Run/vulkan_webgl Bug: angleproject:5064 Bug: b/162082698 Change-Id: I466df9237136dd59a9556faa8cf2dbad94e076fe Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2399509 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Ian Elliott <ianelliott@google.com>
Amy Liu 83c7e1ae 2020-09-17T16:42:19 Fix the regression of color blit. Move the offset aligning code to stencilBlitResolveNoShaderExport to avoid affecting color blit. Test: dEQP-GLES3.functional.fbo.blit.default_framebuffer.*_linear_* Bug: angleproject:5044 Change-Id: Ic2ebef94091853146424d567b0035161611ba32d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2416008 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 22d30378 2020-09-15T23:19:48 Vulkan: Change VK suffix to Vk For consistency with the rest of the backend. Level index variables were using the VK suffix while color index variables used Vk. Bug: angleproject:4881 Change-Id: I0c2799da34cdfe19cb04adbebba042ac8876af96 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2413155 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Charlie Lao 71e7a5a6 2020-09-14T13:56:19 Vulkan: Move mAttachedColorBufferMask to FramebufferState This moves the bit mask of attached color buffer to front end. No function change is expected. Bug: b/167301719 Change-Id: I4eec3a419560b91875260b812a036ceaaeb6b5bb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2410790 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 06b4fb92 2020-09-11T21:24:46 Vulkan: Fool proof packed attachment index to vulkan and from OpenGL ANGLE packs FBO attachments from OpenGL and uses packed attachments to create VkFramebuffer and renderpass. When we use attachment index into the attachment array, we must be very careful to use packed index for vulkan objects. It is easy to make mistakes here and introduce hard to debug bugs. This CL defines a PackedAttachmentIndex class that uses that to index into vulkan attachments and pass around APIs so that compiler would catch the error when wrong index is used. This also introduces PackedClearValuesArray that stores clear value in packed attachment index so that it is impossible to mix it with ClearValuesArray that stores clear value in GL attachment index. Bug: b/167301719 Change-Id: I68680522c60beeb5096e5211eaef89da28c7097e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2410366 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Charlie Lao e4e2a016 2020-09-01T11:23:09 Vulkan: Use color mask to handle draw buffer disabled case When draw buffers set to GL_NONE, instead of remove the attachment from renderpass which breaks renderpass, we force vulkan's per buffer color mask to false while keep the disabled draw buffer attached. This CL also always create FrameBuffer with all color attachments regardless it is enabled or not. Bug: b/167301719 Change-Id: Ice9fca9aacf774a47d13b749f822b222cc050174 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2389007 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Amy Liu b3c7d39a 2020-09-03T15:51:02 Align the sample position in blitResolveStencil compute shader The input coordinates of blitResolveStencil compute shader start from 0,we need to align the sample position to start from 0 if x/y is flipped. Test: dEQP-GLES3.functional.fbo.invalidate.*.unbind_blit_msaa_* Bug: b/159995959 Change-Id: If0c9f5b7cacddbe1a2d7062469a757a63bcc1378 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2392162 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Ian Elliott 4a41204d 2020-09-02T05:04:33 Vulkan: Improve invalidate for depth/stencil Improve state tracking when the depth and/or stencil attachments are invalidated. Since no draw-time tracking is done, we use the number of command-buffer commands to determine when an attachment is drawn to. That allows all cases to be handled for store ops. Still need to handle mContentDefined at endRP time (we have the data, just not the plumbing). Test: angle_white_box_tests --gtest_filter=VulkanPerformanceCounterTest.*Invalidate*/* Test: angle_deqp_gles3_tests --gtest_filter=dEQP.GLES3/functional_fbo_invalidate_* --use-angle=vulkan Bug: b/167276207 Change-Id: Iae10857dbb4d43b934c51ad7e400b71ae0db4f55 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2378670 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi cba9bbbe 2020-09-02T09:55:31 Vulkan: Fix resolve-with-subpass retaining resolve attachment The temporary resolve attachment used to optimize blit was not removed from the framebuffer and render pass descriptions, resulting in subsequent draws to be resolved again. Bug: b/159903491 Change-Id: I9a9c90d25cb07ba9a25999f808b164f9085387d0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2390441 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi b2944fcf 2020-09-02T11:10:00 Vulkan: Don't break the RP on masked/scissored clears Bug: b/166809097 Change-Id: Iedd10a6528808e859c5693a2d30c98aca1a1159c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2390862 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi d701eae2 2020-09-02T12:23:21 Vulkan: Fix resolve with different formats vkCmdResolveImage and subpass resolve attachments cannot be used if the source and destination formats aren't identical per Vulkan spec: vkCmdResolveImage: > srcImage and dstImage must have been created with the same image > format VkSubpassDescription: > each resolve attachment that is not VK_ATTACHMENT_UNUSED must have the > same VkFormat as its corresponding color attachment Bug: chromium:1123524 Change-Id: Iaf7182dbcad0420483ac2c23d0acf8c109688565 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2390781 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Nicolas Capens <capn@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 543a3962 2020-09-02T09:40:10 Vulkan: Fix resolve-with-subpass with non-zero read attachment The draw framebuffer's color index was used to get the read buffer of the source framebuffer. Bug: b/159903491 Change-Id: I7a1626e6732367c14d46f1e1be4057998fdbf011 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2390440 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi a0d048a4 2020-08-27T12:03:02 Vulkan: Fool-proof usage of GL and VK level indices Using boxed types, this change allows the compiler to catch errors when a level index in one space (e.g. GL) is mistakenly used in another space (e.g. VK). This change uncovered a number of bugs due to such mistakes which are fixed. Mistakes are still possible when the index is explicitly extracted, for example to be given to a Vulkan command, or when it's created, for example when retrieved from gl::ImageIndex::getLevelIndex. Future work can include using gl::LevelIndex in gl::ImageIndex directly to alleviate the latter at least. Bug: angleproject:4880 Change-Id: I6427c68c3bc096f771402f51c8554d8171758aa9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2380232 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Courtney Goeltzenleuchter a08495d9 2020-08-27T13:47:19 Revert "Vulkan: restore mContentDefined at endRP()" This reverts commit 53ee431e3d36692cbe50a96ebbf0ff898ec4d523. Bug: chromium:1122621 Change-Id: Ifd63aa0694e00ed6ef74b385466b874604355e79 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2380610 Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Ian Elliott 53ee431e 2020-08-21T12:40:03 Vulkan: restore mContentDefined at endRP() CommandBufferHelper will keep a pointer to the depth-stencil RenderTargetVk, and use this to set RenderTargetVk::mContentDefined to true at the end of a render pass. Test: angle_white_box_tests --gtest_filter=VulkanPerformanceCounterTest.InvalidatingAndUsingDepthDoesNotBreakRenderPass/* Test: angle_deqp_gles3_tests --gtest_filter=dEQP.GLES3/functional_fbo_invalidate_* --use-angle=vulkan Bug: b/163854287 Change-Id: I891381825ee01e141dfa4f9099d07d9ffc943f77 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2368194 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi 295d2ccd 2020-08-24T14:46:31 Vulkan: Generate perf warnings on suboptimal paths Using KHR_debug features, this change creates a performance-warning-generation macro and employs it in a handful of locations to provide useful feedback to application developers. The warnings added in this change are not exhaustive. Bug: angleproject:3461 Bug: angleproject:4900 Change-Id: Id62435d170d90c5be9c1c5cab2d6779ccb58345e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2372628 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Ian Elliott ba1e049f 2020-08-21T13:13:54 Vulkan: Fix compilation error Two commits conflicted and the bots didn't catch it somehow Bug: b/163854287 Change-Id: Idb4d7802eec71b2112b11e4553e609b532cee070 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2369261 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Ian Elliott 296d3bfd 2020-08-21T10:38:32 Vulkan: do not end render pass when invalidating Initially, FramebufferVk::invalidateImpl() was very conservative and always ended a render pass (if the framebuffer is part of the current render pass). This adversely affects PUBG Mobile, which invalidates the depth buffer every frame, causing the render pass to be split. Test: PUBG MOBILE on Android Test: angle_white_box_tests --gtest_filter=VulkanPerformanceCounterTest.InvalidatingAndUsingDepthDoesNotBreakRenderPass/* Test: angle_deqp_gles3_tests --gtest_filter=dEQP.GLES3/functional_fbo_invalidate_* --use-angle=vulkan Bug: b/163854287 Change-Id: I343dee1db3ebaf039ff92557f9ef25b24bcdcc93 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2352627 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Jamie Madill 682f9141 2020-08-18T10:57:40 Remove feedback loop support from back-end. Front-end detection still in place and will be removed in a follow-up. Removes the Vulkan feature and the special clear handling. Bug: angleproject:4959 Change-Id: I5d44c3f7dbdb49d8aa0375f54b7148df09732ba2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2363208 Reviewed-by: Tobin Ehlis <tobine@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill d3e800e9 2020-08-15T17:26:04 Vulkan: Restart RenderPasses in DS read-only mode. We can combine an initial RenderPass with a read-only RP if the first RP never writes to depth. We can check the depth-write tracking in CommandBufferHelper and substitute in a new Framebuffer/RP Desc in this case as well as issue new layout barriers. We need to disable barrier merging in this special case. This reduces the RenderPass count in the Manhattan trace from 15->13. The performance on the Pixel 4 benchmark goes to ~82% of native for the on-screen version and ~88% for off-screen. There's also a ~5% bump in speed for the desktop trace. Bug: angleproject:4959 Change-Id: I70241824f75eaa1e11b50370f826abc36e91686e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2358772 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Jamie Madill e689d316 2020-08-14T22:51:03 Vulkan: Don't end RenderPass on DS feedback loops. Instead of always switching the Framebuffer to mask out depth/stencil loops we now switch the RenderPass to a "read-only" depth/stencil mode. Reduces the RenderPass count in Manhattan from 18->15. There are still a couple extra RenderPasses inserted that we can get rid. We can merge a few RenderPasses by retroactively changing a started RenderPass to "read-only" when there are no prior recorded depth writes or clears. Also adds a test to count the number of RenderPasses ANGLE generates in DS feedback loop situaions. Bug: angleproject:4959 Change-Id: I1855a45959655fc27ccd47a3469c1c672fc8fd9e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2357973 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Tim Van Patten dff47d5f 2020-07-14T19:10:12 Vulkan: Optimize MSAA using subpass resolve attachments If a user is performing a blit to resolve a multisample color buffer into a single attachment, ANGLE can use subpass resolve attachments to resolve directly into the destination buffer as part of the render pass. This allows the data to remain in tiler memory and reduce the extra bandwidth required to write the multisampled data back to perform the copy. This work also requires restoring/reopening a render pass if it has been finished already, assuming the finished render pass was started and for the framebuffer that is the source for the blit command. Other objects that were created when the render pass was started need to be updated as well, such as the source FramebufferVk's resolve attachment, the CommandBufferHelper's vk::Framebuffer and vk::RenderPassDesc, etc. While this is better than performing vkCmdResolveImage(), there is still another major part of optimizing MSAA using resolve attachments not implemented here: discarding the multisampled image rather than writing it to GMEM, which requires the user to invalidate the read FBO after the blit. This CL was verified with AGI to make sure there are no explicit blits to resolve the multiple sampled image. Bug: b/159903491 Test: FramebufferTest_ES31.*Blit* Test: VulkanPerformanceCounterTest_ES31.MultisampleResolveWithBlit Change-Id: I320a26088d8f614a295e7feec275d71310391806 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2298663 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Jamie Madill 594e0e14 2020-08-15T16:35:55 Vulkan: Add DS ReadOnly mode to Framebuffer/RP caches. Allows ANGLE to create Framebuffers and RenderPasses with a read- only depth/stencil layout. Also allows us to transition our Images to this new DepthStencilReadOnly layout. Internal code redesign. No functional change to our command stream. Bug: angleproject:4959 Change-Id: I9b80063bdaec8f5d6c89037e0618c85e1c11b78d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2354280 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill eb85c021 2020-08-05T15:07:15 Vulkan: Refactor Context CommandBuffer query. getOutsideRenderPassCommandBuffer returns the command buffer directly since it's now stateless and cannot throw an error. All the RenderPass begin/end and flushing are done by the dependency functions (buffer/ image read/write). Bug: angleproject:4911 Change-Id: I5e7806be9d0e1b5e358524bd485298d660fac942 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2339544 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill d201ed8b 2020-08-02T16:29:35 Vulkan: Track used Images in RenderPass. Adding a simple ImageSerial tracking map in our RenderPass allows us to know when we do or do not need to close the RenderPass on a new Image access. This simple tracking scheme improves Manhattan performance by up to 25% on Android. The improved perf comes from reducing our RenderPass count (23->18 RenderPasses in our capture scene). Adds a FastUnorderedSet class to manage the used RP Image serials. Updates the Query helpers to explicitly flush the RP before inserting queries. Bug: angleproject:4911 Change-Id: I0c34fc8e307514ebdf3e81e08d8e5aedb70ebe8f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2334346 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 5559351c 2020-08-11T14:23:32 Vulkan: Correctly determine mip level in resolveColorWithCommand() FramebufferVk::resolveColorWithCommand() is currently using the wrong mip level value by using the GL index value, rather than calculating the VK value from (index value - the base level). Bug: angleproject:4753 Test: FramebufferTest_ES31::MultisampleResolveIntoMipMapWithBlit() Change-Id: I8ddaeb21c4957b46880f5ef5f6a78242c04b4dcd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2349951 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Jamie Madill 5921a040 2020-08-06T17:39:56 Vulkan: Refactor image dependency commands. Uses commands similar to the Buffer APIs. Also updates docs. Bug: angleproject:4911 Change-Id: I1f2ec9bdd1d725d4ec3d6601e63bcb0c045e2121 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2342287 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Jamie Madill 3d17084d 2020-08-06T17:53:36 Vulkan: Simpify check for started RenderPass + FB. We can check the RenderPass CB helper directly instead of caching a separate variable. Bug: angleproject:4911 Change-Id: Ic953c101c64fd5142e2dedfd06e3fea287331fd4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2341761 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 81370214 2020-07-29T12:54:02 Pass the Command when sync'ing dirty objects A new enum is being created that contains command types, which are then passed to each dirty object when they are synced. This allows the syncState() methods to perform special handling for each command type. This change is in preparation for optimizing resolving multisample images with glBlit, since the render pass needs to be updated before it's ended. Bug: angleproject:4753 Change-Id: I77701f79418d35cff689e864c8a8b47b6fca0255 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2327335 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 23daea2f 2020-08-06T10:40:00 Vulkan: Rename CommandBuffer get method. This method will no longer end the RenderPass in a following CL. Renaming it in a split CL makes the review diff simple. Bug: angleproject:4911 Change-Id: Id48257884dccb7c86f7de2cc9ca95e651fb68df7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2340788 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill adc250c3 2020-07-31T21:11:05 Vulkan: Refactor ImageViewHelper serials. Instead of storing a dictionary of serials to specific image views we now store a single 32-bit serial combined with subresource info. The serials combined with a subresource info (level/layer) gives a unique identifier for each ImageView in the ImageViewHelper for the descriptor set cache and the Framebuffer cache. Also moves ImageView serial allocation to initialization and release. This means we no longer need to use "getAssign" methods and instead we use a few init methods to ensure the serials stay allocated. Bug: angleproject:4911 Change-Id: Ia6af76ae16b3ff5d4a83974bde05cc704064b079 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2333395 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi f776eb9c 2020-08-01T23:45:24 Vulkan: EXT_multisampled_render_to_texture2 support The previous change that implemented EXT_multisampled_render_to_texture already provisioned this extension in the Vulkan backend. This change implements the front-end for this extension and enables it in the Vulkan backend. Bug: angleproject:4836 Change-Id: I7080260972e61727c5716051c236f635668cb67b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2330510 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Shahbaz Youssefi 47207e42 2020-08-01T23:43:43 Vulkan: Fix blit/resolve of mixed-samples framebuffers A framebuffer could contain a mixture of multisampled and multisampled-render-to-texture attachments. When used as the source of a glBlitFramebuffer operation, the former requires a resolve while the latter is a blit. This change fixes this use-case. Bug: angleproject:4836 Change-Id: I1d39bf25f54df9f8b68304058596a2d1c975f9ba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2333987 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0