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

src/libANGLE/renderer/vulkan/FramebufferVk.cpp

Log

Author Commit Date CI Message
Charlie Lao 43187a24 2023-10-25T09:43:56 Vulkan: remap YUV clearColor component from GL order to vulkan order For EXT_YUV_TARGET, OpenGL and vulkan uses difefrent mapping between YUV to RGB. OpenGL spec says "When clearing YUV Color Buffers, clear color should be defined in yuv color space and so floating point r, g, and b value will be mapped to corresponding y, u and v value and alpha channel will be ignored.", but vulkan spec says "Values in the G, B, and R channels of the color attachment will be written to the Y, CB, and CR channels of the external format image, respectively.". This CL adjusts clear color to remap the clear color from GL ordering to vulkan ordering. This CL also adds a temporary workaround for ARM driver bug where they were looking at unused color attachment instead of resolve attachment. Bug: b/223456677 Change-Id: I9800bffc18ccd9d77b4e86995161cdde06257e1f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4973355 Reviewed-by: Chris Forbes <chrisforbes@google.com> Commit-Queue: Chris Forbes <chrisforbes@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 889b01ef 2023-10-17T12:13:10 Vulkan: Fix VK_android_external_format_resolve VVL error part 1 VUID-VkSubpassDescription2-nullColorAttachmentWithExternalFormatResolve-09337: The Vulkan spec states: If the nullColorAttachmentWithExternalFormatResolve property is VK_TRUE and pResolveAttachments is not NULL, for each resolve attachment that has a format of VK_FORMAT_UNDEFINED, the corresponding color attachment must have the value VK_ATTACHMENT_UNUSED VUID-VkFramebufferCreateInfo-attachmentCount-00876 The Vulkan spec states: attachmentCount must be equal to the attachment count specified in renderPass Fix assertion in FramebufferVk::getFramebuffer() Bug: b/223456677 Change-Id: I538a44753a2ba9b432fa3b1814748942cd8a3500 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4948652 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Yuxin Hu cfc40d2b 2023-07-19T17:47:13 Vulkan: Adjust clear color precision for GL_RGB5_A1 FBO When clear color has more precision than the framebuffer format can hold, dithering is automatically applied on some hardware. This issue causes below dEQP tests to fail when the FBO color attachment format is RGB5_A1: KHR-GLES31.core.draw_buffers_indexed.color_masks KHR-GLES32.core.draw_buffers_indexed.color_masks Adjust the clear color precision for RGB5_A1 format to workaround the issue. We can remove this workaround once the vulkan driver fixes the auto-dithering problem. Bug: b/292282210 Change-Id: Ic3ffebd2d20c8782612619a60d1ec2cc6d613c22 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4937472 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 2e11fcc5 2023-10-16T16:40:35 Vulkan: Fix assertion when YUV image attached to resolve attachment When YUV image attached to resolve attachment, mSamples is 1. Righ now the code assumes resolve is a MSRT attachment, so it asserts mSamples>1. This CL adds a new API packYUVResolveAttachment so that we can assert properly for YUV and MSRT. Bug: b/223456677 Change-Id: Ib65fd3fe1e6561b85395cc27204bbd85c1f464c3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4942907 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Chris Forbes <chrisforbes@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 58ffa778 2023-10-11T09:41:23 Vulkan: Implement YUV_TARGET use VK_ANDROID_external_format_resolve This implements EXT_YUV_TARGET using VK_ANDROID_external_format_resolve extension. This CL is based on Chris Forbes's CL on android gerrit. Bug: b/223456677 Change-Id: Ieb6970a0787b0c2a72a76b208695a678d2c79e80 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4857459 Reviewed-by: Chris Forbes <chrisforbes@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi adb17c80 2023-10-06T10:39:17 Vulkan: Copy 3D<->2DArray images with vkCmdBlitImage anyway Despite the validation error, do the copy with vkCmdBlitImage anyway. Drivers seem to work correctly, and the validation restrictions seem unintentional. Bug: angleproject:7291 Change-Id: Ie7a0ecfe559be44738da3eada281ea97424b38ab Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4916359 Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 8c341cfd 2023-10-04T12:49:59 Vulkan: Fix blits involving 3D images The layer vs depth value involved with 3D images when calling vkCmdBlitImage is fixed in this change. However, that brought to light that the combination of VUID-vkCmdBlitImage-srcImage-00240 and VUID-vkCmdBlitImage-dstImage-00252 make it impossible to blit between 3D and 2D array images, which is likely a spec oversight. This change makes 3D<->2DArray blits fall back to draw-based blit. This in turn exposed the fact that 3D images as src were not handled in BlitResolve.frag. A new Blit3DSrc.frag shader is added which shares code with BlitResolve.frag to implement this. This is a separate shader to avoid creating unnecessary and invalid combinations of shaders. VK_EXT_image_2d_view_of_3d could have been used to avoid this new shader, but that is not ubiquitous. Bug: angleproject:7291 Bug: dawn:1962 Change-Id: I6a96162f95829304b4731d43208d9d054f538105 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4911800 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Mohan Maiya 6b0ddce0 2023-09-22T13:13:38 Backends need to handle invalid render area during a clear 1. Frontend no longer noops empty scissors during clear 2. FramebufferVk is updated to handle invalid render area by restaging deferred clears in clearImpl(...) if render area is invalid Bug: angleproject:8348 Tests: EGLSurfaceTest*WindowThenScissoredClear* Change-Id: Iec51914a083a59bad7f939798c932dffada56a6c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4867641 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Mohan Maiya 826e5f95 2023-09-24T09:48:55 Vulkan: Rename redeferClears as restageDeferredClears This is a simple rename to better reflect implementation and has no functional changes. Bug: angleproject:8348 Change-Id: I53ce42e8bb14687a0dda167b8d79eba1eb357254 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4888691 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Geoff Lang 430a4f55 2023-07-21T13:45:52 Fix read size validation for RGBX formats. GL_RGBX8_ANGLE is the only format where the upload format is 3-channel RGB, whilethe download format is 4-channel RGBX. As such, the internal format corresponding to format+type expects 3-byte input/output. The format is fixed here for readPixels to output 4 bytes per pixel. Bug: chromium:1458046 Change-Id: Iec737ed64bade003cfab50dc5f595eb4875e81e4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4706957 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Roman Lavrov c0f2f71e 2023-06-27T16:00:09 Use VK_EXT_legacy_dithering when available instead of emulation Yields improvement in gpu power: http://b/284462263#comment45 Bug: b/284462263 Change-Id: I5bfd115557b6baac17c05639118feaebf19c5cd4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4652590 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Roman Lavrov <romanl@google.com>
Charlie Lao 6ffd0d20 2023-07-12T12:09:45 Vulkan: Clean up depth stencil feedback mode part 2 Right now the tracking of depth stencil buffer readOnly or feedback loop is in FramebufferVk class. This really belongs to ContextVk, since it is not a permanent state of framebuffer, but current state of context. This CL moves it to ContextVk and changes to use BitSet instead of four boolean. Bug: b/289436017 Change-Id: I955c439259935f82eff30ddfff776a69723e5d0d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679886 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao a33ec5dd 2023-07-11T18:01:12 Vulkan: Clean up depthStencil feedback loop implementation Part1 This is first clean up effort for depth stencil feedback loop implementation. This CL moves updateRenderPassStencilReadOnlyMode and updateRenderPassDepthReadOnlyMode methods from FramebufferVk to RenderPassCommandBufferHelper class. The method is actually updating renderPass's state, not FramebufferVk's state. In the next CL, FramebufferVk will be removed from the argument as well. With this change, I also removes updateStartedRenderPassWithDepthMode() and updateStartedRenderPassWithStencilMode() to use updateStartedRenderPassWithDepthStencilMode() directly. This CL is mechanical changes only, no behavior chnage is expected. Bug: b/289436017 Change-Id: Id3960f973a7115c05ebea199cb8ef802e995941a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679365 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao f5986fbb 2023-07-11T12:11:20 Vulkan: Dont break RP if there is actual render feedback loop There is a bit terminology confusion here that will be fixed in next CL. If a depth attachment is read only, then there is no feedback loop, we should not call feedback loop for read only depth attachment. The real depth render feedback loop mode is formed when we write to depth and sample from depth at the same time. In this condition, the content is undefined per OpenGLES spec section 9.3.1 (https://registry.khronos.org/OpenGL/specs/es/3.2/es_spec_3.2.pdf). The shouldSwitchToReadOnlyDepthStencilFeedbackLoopMode() implementation handles the usage case that the same render pass has depth write and then switch to read only. Under this usage there is no actual feedback loop, and we should still work properly by end current render pass and start a new render pass with read only depth attachment. This implementation also treating the actual feedback loop case exactly the same way by ending render pass first, even though this is undefined behavior. gangstar_vegas has the exact this undefined behavior usage case, where it write and sample from depth buffer at the same draw call. Native driver is not ending the render pass but ANGLE currently does. This puts ANGLE into worse performance. Since this is undefined behavior, either way is correct. This CL checks if there is an actual feedback loop in the current render pass and if yes, we adopt the native driver's behavior that keep the current render pass going. This improves gangstar_vegas frame time from 4.365ms to 3.89ms, and interestingly, yield the same golden image. Bug: b/289436017 Change-Id: Ifc04ecd8ad6455a88e8615bd5452b9cce88c6687 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679361 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Alexey Knyazev 0e7c79e3 2023-06-29T00:00:00 Vulkan: Fix resolve with multiple targets of different formats Ensure that the appropriate code path is taken when resolving into multiple target buffers of different formats. Bug: chromium:1123524 Change-Id: Ic25a52ba069a2209c907226613fde1109823c094 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4650561 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Shahbaz Youssefi e394cb46 2023-06-10T23:12:35 Vulkan: Refactor framebuffer fetch shader emulation This change fixes simultaneous usage of EXT_shader_framebuffer_fetch and ARM_shader_framebuffer_fetch, which previously declared two identical input attachment variables. The code is additionally greatly simplified. Bug: angleproject:8196 Bug: angleproject:8197 Bug: angleproject:8198 Change-Id: Iaaa2a5539a95727e67001a4da1d45092c9db4f2c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4615187 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: mohan maiya <m.maiya@samsung.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi f1e19872 2023-06-12T14:38:23 Vulkan: Fix read pixels with RGBX Typically, the format used for data uploads and downloads as well as the storage format are consistent. That is unfortunately not the case for GL_RGBX8_ANGLE where data uploads are through 3-byte RGB pixels while downloads are through 4-byte RGBX pixels. This change swaps out RGBX for RGBA on the read pixels path. Test credit of Jason Macnak <natsu@google.com> Bug: b/246008627 Test: atest CtsSkQPTestCases Change-Id: I531ebd8318bf4fe5ac09c623068b790a7e301428 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4608488 Reviewed-by: Jason Macnak <natsu@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Charlie Lao fa9172a3 2023-03-27T09:49:33 Reland "Vulkan: Use midRenderPass clear if RP has started but inactive" This is a reland of commit 98151770adfd990c533991da27615b4879494307 Original change's description: > Vulkan: Use midRenderPass clear if RP has started but inactive > > This CL extends prior CL's optimization so that if clear is issued right > after blitFramebuffer call (this could make sense if blit and clear are > on different buffer), we can keep the started render pass and do the > midRenderPass clear instead of endRenderPass and start another > renderPass. > > Bug: b/273808966 > Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Bug: b/273808966 Change-Id: I5c8c85c173f021a7753ef579f83d9ceb24147a7c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4442911 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 2f19bb74 2023-03-16T16:03:29 Reland "Vulkan: Reactivate already started render pass when possible" This is a reland of commit ad9537af7f2bb5e22bc73f4e833fd3789adaa217 Original change's description: > Vulkan: Reactivate already started render pass when possible > > In some usage case (such as lineage_mobile), we are seeing in the middle > of render pass, app switch to another fbo just to issue a glClear() > call, which the clear call itself gets deferred. Application then switch > back to the original frame buffer. Before this CL, the render pass gets > recreated due to frame buffer binding change, even though the clear gets > deferred and new render pass and the previous render pass are > essentially the same. This CL detects this situation and reactivate the > current render pass instead of creating a new one. With this CL, > lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only > one render pass is used instead of two. > > This CL also allows the render pass started by BlitFramebuffer reused by > subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL > reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7 > pro) > > Bug: b/273808966 > Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713 > Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/273808966 Change-Id: Ice9062122ae320b1a0108ff981bc65bd13b2ada0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4406888 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 41f0a321 2023-04-03T21:58:43 Revert "Vulkan: Reactivate already started render pass when possible" This reverts commit ad9537af7f2bb5e22bc73f4e833fd3789adaa217. Reason for revert: Suspected cause for flakiness. anglebug.com/8118 Original change's description: > Vulkan: Reactivate already started render pass when possible > > In some usage case (such as lineage_mobile), we are seeing in the middle > of render pass, app switch to another fbo just to issue a glClear() > call, which the clear call itself gets deferred. Application then switch > back to the original frame buffer. Before this CL, the render pass gets > recreated due to frame buffer binding change, even though the clear gets > deferred and new render pass and the previous render pass are > essentially the same. This CL detects this situation and reactivate the > current render pass instead of creating a new one. With this CL, > lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only > one render pass is used instead of two. > > This CL also allows the render pass started by BlitFramebuffer reused by > subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL > reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7 > pro) > > Bug: b/273808966 > Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713 > Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/273808966 Change-Id: I81cc2dcacb52466808b2ccf5819feda466c39fc5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4396502 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 96cda1ac 2023-03-31T15:08:11 Vulkan: Switch to modified framebuffer should trigger submit The feature flag preferSubmitAtFBOBoundary intended to trigger submitCommands call when FBO is switched. Right now there is a bug that when FBO is switched, submitCommands did not get called even if feature is enabled. The reason is that when framebuffer changed, we first get FramebufferVk::syncState call, and if the FBO that we switched to is drity, we will end up calling ContextVk::flushCommandsAndEndRenderPass to immediate end the render pass. The problem with that is that later on when we get to ContextVk::syncState and saw DIRTY_BIT_DRAW_FRAMEBUFFER_BINDING dirty bit and try to issue a submit, we notice render pass already ended, so mHasDeferredFlush never gets set, which means we never call submitCommands. All apps render to system framebuffer in the last render pass, and system framebuffer is always dirty due to swap chain image rotation, we hit this almost with every app. This CL avoid flushCommandsAndEndRenderPass() call from FramebufferVk::syncState. We now relies on ContextVk::onFramebufferChanged (which calls onRenderPassFinished() which will set DIRTY_RENDER_PASS bit to trigger deferred endRenderPass) to end the current render pass. This CL also add a regression test to ensure the submit indeed occur. Bug: b/275624771 Change-Id: I92b95a7a6c435f242d6684cb7852172cf41896c3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4390642 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Roman Lavrov <romanl@google.com>
Shahbaz Youssefi c5e9de23 2023-04-03T15:14:03 Revert "Vulkan: Use midRenderPass clear if RP has started but inactive" This reverts commit 98151770adfd990c533991da27615b4879494307. Reason for revert: Suspected cause for flakiness. anglebug.com/8118 Original change's description: > Vulkan: Use midRenderPass clear if RP has started but inactive > > This CL extends prior CL's optimization so that if clear is issued right > after blitFramebuffer call (this could make sense if blit and clear are > on different buffer), we can keep the started render pass and do the > midRenderPass clear instead of endRenderPass and start another > renderPass. > > Bug: b/273808966 > Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Bug: b/273808966 Change-Id: I7a11635a6eceafb6f4fb3a0d95f6627ee98321c0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4393497 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 98151770 2023-03-27T09:49:33 Vulkan: Use midRenderPass clear if RP has started but inactive This CL extends prior CL's optimization so that if clear is issued right after blitFramebuffer call (this could make sense if blit and clear are on different buffer), we can keep the started render pass and do the midRenderPass clear instead of endRenderPass and start another renderPass. Bug: b/273808966 Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao ad9537af 2023-03-16T16:03:29 Vulkan: Reactivate already started render pass when possible In some usage case (such as lineage_mobile), we are seeing in the middle of render pass, app switch to another fbo just to issue a glClear() call, which the clear call itself gets deferred. Application then switch back to the original frame buffer. Before this CL, the render pass gets recreated due to frame buffer binding change, even though the clear gets deferred and new render pass and the previous render pass are essentially the same. This CL detects this situation and reactivate the current render pass instead of creating a new one. With this CL, lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only one render pass is used instead of two. This CL also allows the render pass started by BlitFramebuffer reused by subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7 pro) Bug: b/273808966 Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 7eb6869a 2022-08-30T16:28:08 Vulkan: Change ResourceAccess::Write to ResourceAccess::ReadWrite AS a preparation for the next CL which will optimize for WriteOnly access, this CL changes Write to ReadWrite and adds WriteOnly access (but not used yet). Mechanical changes only and no function difference is expected. Bug: b/243711628 Change-Id: I509d6045ae87635e24076b646af42f35d88d52cf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3866672 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi 3886af6e 2023-01-16T15:17:40 Vulkan: Generalize AHB optimization prohibitions ... to all external images. Bug: angleproject:7962 Change-Id: Ib8e090b995330b651865953057869adb4d14c83b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4169559 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Mohan Maiya 90b6d511 2023-01-13T10:06:12 Vulkan: Add support for AHB usage FRONT_BUFFER flag AHB usage flags have been updated to include front buffer usage. AHBs tagged with this flag need to be handled similar to single-buffered window surfaces especially w.r.t glFlush semantics. Account for the new usage flag when deferring flushes. Bug: angleproject:7956 Test: Android VTS GraphicsFrontBufferTests.* Change-Id: I79440d8447ac569c3d785de191815d2d2f3f069f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4167063 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Charlie Lao 410d8ba5 2022-12-21T13:27:00 Vulkan: Cleanup ContextVk::hasStartedRenderPass APIs ContextVk has a few hasStartedRenderPass APIs which interpret "start" inconsistently. A RenderPassCommands' life should be notStarted, started, requestEnd, and end (which is equivalent to notStarted). When someone calls onRenderPassFinished on a started renderpass, it does not immediate endRenderPass, but it will set DIRTY_BIT_RENDER_PASS dirty bit so that next draw call will trigger endRenderPass and start a new renderPass. We do not have a name for this state, which adds some confusion. This CL renames the stage between start and onRenderPassFinished to be "active" renderpass, when you have mRenderPassCommandBuffer pointer being valid and you can actively adding draw commands into the renderPass. For this purpose, I haves renamed hasStartedRenderPass to hasActiveRenderPass. This CL also simplifies hasStartedRenderPass implementation to only check mRenderPassCommandBuffer and turned mRenderPassCommands.started as assertion. This CL also changes hasStartedRenderPassWithQueueSerial to actually check mRenderPassCommands.started instead of being "active", so that name reflects what it is actually checking. This CL also changed hasStartedRenderPassWithCommands to hasActiveRenderPassWithCommands to make name and implementation consistent. One added benefit of this is that after this CL we now allow load/store optimization on a started but inactive renderPass as well (for example glInvalidateFramebuffer call after glFenceSync call, or invalidate after FBO blit as demonstrated by MultisampleResolveTest.ResolveD32FSamples tests). Bug: angleproject:7903 Bug: angleproject:7551 Change-Id: I8c8ec4c0d54b9ad0a9e373108dfce6b151c8fe0e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119693 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Yuxin Hu 5f1ab1d1 2023-01-03T11:48:51 Fix Deferred Flush Bug On Android Hardware Buffer When does app read from Android Hardware Buffer is outside of ANGLE's control. If we defer glFlush, it is possible that when the app is reading from AHB, the commands have not been flushed and executed, causing app to read unexpected data. This change adds a check to not defer glFlush when the Framebuffer draw attachment is Android Hardware Buffer. Bug: b/262886794 Change-Id: Ie0606f71b1a4f4f20511b7327e7ffb8c096ac727 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4126700 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi 6c41793f 2022-12-20T15:20:50 Vulkan: Use read/write depth/stencil layouts This allows an application to have depth in read-only feedback loop while stencil is being written to for example. Bug: angleproject:7899 Bug: b/192477489 Change-Id: Ic2e11d32da7c7e3a7f3cd86dbafc5c56a0dbbfd7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116730 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 412dd368 2022-10-05T23:51:52 Vulkan: Use vkCmdClearAttachments for unmasked scissored clears Building on work by Tim Van Patten <timvp@google.com> In https://chromium-review.googlesource.com/c/angle/angle/+/3388635, not only were unmasked scissored clears made to use vkCmdClearAttachments, but also scissored clears could use loadOp=Clear. While this is potentially faster, it comes with a number of complications. This change only does the former. Unfortunately, due to a Qualcomm driver bug that forces ANGLE to avoid vkCmdClearAttachments, code simplification in the draw path cannot be made. Bug: angleproject:5194 Change-Id: Iec4184a09ca7fd09e3e8148c53db503512e6b8f0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3935893 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 8181c056 2022-11-22T15:34:48 Vulkan: Remove RenderPassSerial RenderPassSerial was introduced to uniquely identify a RenderPassCommands. With the work of per current context queue serial, now every started RenderPassCommands already have a unique QueueSerial. This CL removes RenderPassSerial and use renderPass's queueSerial instead. Bug: b/255414841 Change-Id: Id0a87319a9132cdb74aba195f1f05aa31454592b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4049966 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi 2dde7357 2022-11-16T10:39:32 Vulkan: `const` render passes Bug: angleproject:7369 Change-Id: I1ee1449bd8ea8c6a3e26e50a7f3734fad91dc911 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4031488 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi fbd7d5fa 2022-10-17T17:20:09 Move thread pool classes to common/ In preparation for access by image_util files. Bug: b/250688943 Change-Id: I24777269a5071eae9a60f939635d01ed7246461f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961454 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 9b5fff82 2022-10-05T21:56:00 Vulkan: Emulate shader stencil export for MSRTT The MSRTT emulation code had one corner case issue that could lead to performance and memory inefficiencies. That is when stencil needs to be unresolved and VK_EXT_shader_stencil_export is not supported. This change adds a path to emulate VK_EXT_shader_stencil_export and removes this inefficiency. This should help Chromium on older Android devices that lack both this and the recent VK_EXT_multisampled_render_to_single_sampled extensions. Chromium frequently breaks the render pass (crbug.com/1336981), which easily leads to this situation. Bug: angleproject:4836 Change-Id: Ifceec43f7f3807b7e32f4b379edcd4351ae76414 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3935892 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi c19ec948 2022-08-23T10:43:59 Vulkan: Implement imageless framebuffers * Added the attachment image and create info objects to be used for imageless framebuffers created in getFramebuffer(). * New helper class for framebuffers in RenderPassCommandBufferHelper: MaybeImagelessFramebuffer, which includes a framebuffer object, if the framebuffer is imageless, and the image views. This is to make sure that the args for render pass begin info will be correctly set up according to the status of the used framebuffer. * Refactored the collection of attachments in getFramebuffer() into a new function, getAttachmentsAndImagesFromRenderTargets(). It also returns their corresponding ImageHelper* objects used to create the framebuffer (from their image properties). * New struct: RenderTargetInfo; which keeps track of render targets and whether resolve image should be used for the render pass in the form of the enum class RenderTargetImage. * Added a new arg to getFramebuffer(): resolveRenderTargetIn; to use when there is a valid resolveImageViewIn. * Without using the framebuffer cache, we would require to handle the framebuffer destruction by adding it to the garbage instead of releasing it. For example, FramebufferVk::destroy() now adds mCurrentFramebuffer to the garbage. * Added new framebuffer unit tests. * Added tests where two textures with different attributes are bound to the same framebuffer before drawing, one after another. * Added test where a blit occurs from a multisample texture into a non-zero level of a resolve texture, each bound to a separate FBO. * Added a new perf test to compare performance for enabled imageless framebuffers vs disabled. (Credit: cclao) Bug: angleproject:7553 Change-Id: Iacdbd73aaa01cbb0e37abf01ae4892bdfdd4b12f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827644 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 06d0389a 2022-10-04T19:26:48 Remove leftover code regarding render pass serial * Removed the render pass serial reset in the function where the current framebuffer is released. (left over from a prior CL.) Bug: angleproject:7553 Change-Id: I61b4a12ac8957f6e1dcd4bf0f4e233c068736dff Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3931901 Auto-Submit: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 5d7c4eca 2022-10-02T02:27:27 Vulkan: Don't flush depth/stencil on color blit When syncing the read framebuffer for blit, deferred clears are picked up for the attachments that are not being synced. They are then redeferred so a future command would pick them hopefully as loadOp. This change improves the frame time of Pretty Derby on Pixel 6 by ~23%. Bug: angleproject:7727 Change-Id: Ie7d84c58315cd09204e5229f1ec73605d5a7f639 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3931973 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Hailin Zhang 836cc5e2 2022-09-09T22:06:22 Vulkan: add etc to bc compute transcoding. use compute shader to transcode etc format to bc format. Bug: b/243398683 Change-Id: Idbd0820a2df8d92fe690055dae2933bc559e9bfd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3888501 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Hailin Zhang <hailinzhang@google.com>
Yuxin Hu 053c6a06 2022-09-20T15:17:28 Vulkan: Add more tests for attachmentless framebuffer This CL adds below test scenarios for attachmentless framebuffer: 1. Create first attachmentless framebuffer with larger size, and create second attachmentless framebuffer with smaller size. 2. Create an attachmentless framebuffer with smaller size, and grow its default width and height. 3. Create an attachmentless framebuffer with larger size, and shrink its default width and height. 4. Create an attachmentless framebuffer with larger size, given it an attachment with a medium size, and shrink its default width and height. This CL also splits the test failure bugs on different vendor and renderer to different bug tickets. This CL addresses a bug on vulkan backend: only skip onFramebufferChange() if the framebuffer has at least one attachment, and mCurrentFramebufferDesc equals to priorFramebufferDesc. Otherwise in test scenario 2 and 3 above, we will use the wrong scissor size, because the FramebufferDesc remains the same before and after changing the default width and height, and we will wrongly skip onFramebufferChange() where we update scissor area to match with the new default width and height. Bug: angleproject:7666 Bug: angleproject:7697 Bug: angleproject:7699 Bug: angleproject:7700 Bug: angleproject:7705 Change-Id: Ieb143b27f8c1a229dab8f43d0a16e3e871185941 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3908332 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Amirali Abdolrashidi b9cd542e 2022-09-15T17:31:35 Vulkan: Use serial to check which FBO has open RP In preparation for the scenario where an imageless framebuffer is shared, checking whether the started render pass belongs to a certain framebuffer is tweaked to use a serial-based method instead of checking the framebuffer handle. * Added the last render pass serial to ContextVk, which increments every time a render pass begins. The serial is also stored in the FramebufferVk object invoking it. * Added the type RenderPassSerial for this purpose. * Serials are generated through a serial factory in ContextVk. * Updated hasStartedRenderPassWithSerial() to match the serials instead of the handles. * Removed the getFramebuffer() calls from FramebufferVk and UtilsVk that are now unused. Bug: angleproject:7553 Change-Id: Id60dcbf7973558d35e55ff4af4c71e50c6853bba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3897970 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Yuxin Hu 0fefbe83 2022-09-14T15:20:00 Vulkan: Do not cache the FramebufferHelper with no attachment If two FBOs don't have any attachments, and their GL_FRAMEBUFFER_DEFAULT_WIDTH and GL_FRAMEBUFFER_DEFAULT_HEIGHT are different, there is no difference in their cache key (vk::FramebufferDesc). Therefore the Vulkan backend is not able to distinguish between the two FBOs. This can create issues when we 1. create first FBO with a smaller size, renders to it 2. create second FBO with a bigger size, renders to it The second renderpass will use the FBO created in the first renderpass, because it managed to retrieve the first FBO from the cache with the same cachekey. This triggers the vulkan validation error: VUID-VkRenderPassBeginInfo-pNext-02853, saying the render area exceeds the framebuffer size. This CL fixed it by not adding the FramebufferHelper to the cache, if it doesn't have any attachment. These framebufferHelpers are cheap, without cache there should not be much performance drop. Bug: angleproject:3579 Bug: angleproject:7351 Bug: angleproject:7666 Bug: b/246334302 Change-Id: Iddecafddb042bd16401f983f9ee1a021b845d8bb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3891543 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Peng Huang 79aa846e 2022-08-17T13:40:33 Reland "Not recreate Framebuffer for eglMakeCurrent() call" This is a reland of commit bf9c815263455403e587a9d2b0fdb9fb8e964208 Original change's description: > Not recreate Framebuffer for eglMakeCurrent() call > > Right now, in eglMakeCurrent() call, ANGLE always release the > default framebuffer object associated to the current context, > and create a new default framebuffer object for the new current > context. It impacts chrome performance, since chrome call > eglMakeCurrent() a lot. With this CL, the default framebuffer > will be created with gl::Context. When the surface is changed > by eglMakeCurrent() call, ANGLE will detach the previous surface > from the associated framebuffer, and attach the new surface to > the next current context's default framebuffer. > > Bug: chromium:1336126 > Change-Id: Iaa747669250ae250245db383a716b4634df59ea4 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827751 > Commit-Queue: Peng Huang <penghuang@chromium.org> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Geoff Lang <geofflang@chromium.org> Bug: chromium:1336126 Change-Id: Iade19004a4335ac7bc6ca176a3c14d34afff8c9e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3877405 Auto-Submit: Peng Huang <penghuang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Peng Huang 02e8497f 2022-09-07T01:12:31 Revert "Not recreate Framebuffer for eglMakeCurrent() call" This reverts commit bf9c815263455403e587a9d2b0fdb9fb8e964208. Reason for revert: compile errors https://ci.chromium.org/ui/p/chromium/builders/try/linux-chromeos-rel/1303510/overview Original change's description: > Not recreate Framebuffer for eglMakeCurrent() call > > Right now, in eglMakeCurrent() call, ANGLE always release the > default framebuffer object associated to the current context, > and create a new default framebuffer object for the new current > context. It impacts chrome performance, since chrome call > eglMakeCurrent() a lot. With this CL, the default framebuffer > will be created with gl::Context. When the surface is changed > by eglMakeCurrent() call, ANGLE will detach the previous surface > from the associated framebuffer, and attach the new surface to > the next current context's default framebuffer. > > Bug: chromium:1336126 > Change-Id: Iaa747669250ae250245db383a716b4634df59ea4 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827751 > Commit-Queue: Peng Huang <penghuang@chromium.org> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Geoff Lang <geofflang@chromium.org> Bug: chromium:1336126 Change-Id: I7c07f62236f57523b29c536c04f9a9de79da2f4b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3877404 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Peng Huang <penghuang@chromium.org> Reviewed-by: Yuly Novikov <ynovikov@chromium.org> Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Peng Huang bf9c8152 2022-08-17T13:40:33 Not recreate Framebuffer for eglMakeCurrent() call Right now, in eglMakeCurrent() call, ANGLE always release the default framebuffer object associated to the current context, and create a new default framebuffer object for the new current context. It impacts chrome performance, since chrome call eglMakeCurrent() a lot. With this CL, the default framebuffer will be created with gl::Context. When the surface is changed by eglMakeCurrent() call, ANGLE will detach the previous surface from the associated framebuffer, and attach the new surface to the next current context's default framebuffer. Bug: chromium:1336126 Change-Id: Iaa747669250ae250245db383a716b4634df59ea4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827751 Commit-Queue: Peng Huang <penghuang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Charlie Lao badfeecd 2022-08-10T14:38:43 Vulkan: Destroy fb1 should not affect fb2 with same attachments If two FBOs has the same attachments. they will share the same VkFramebuffers. Destroy one fbo should not cause trouble for the other fbo. Bug: chromium:1351170 Change-Id: I032da8cc12eb8556c3e325c8fd7a3de9974ae909 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3824302 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 81554b66 2022-07-27T16:53:03 Vulkan: Reduce Framebuffer dirtyBits for swapchain only changes For window system framebuffer, the change to it is very limited. Most time it is only swapchain image changes. Right now we are also setting depth/stencil buffer dirty and processing layer count update and color mask and blending update when only color image changed. This CL avoids setting depth/stencil dirty bit for swap chain image changes. It also avoids color mask and blending update (they still gets updated for draw buffer change or draw franmebuffer binding changes). Bug: b/240475351 Change-Id: I0697a38d5939187244d67f01c0bc53fc28e11664 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3789471 Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Auto-Submit: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Lingfeng Yang c2aaeadb 2022-07-14T13:27:38 Vulkan: Skip nonexistent attachments when calculating samples When FBO 0 is bound, FramebufferVk can get into a state where the color attachment is considered null (such as surfaceless). Then, getSamples() is called with null color attachment, resulting in an assertion or nullptr crash. Fix getSamples() to respect the color attachments mask. The entry point that brought this about was also a dispatch, not a draw. In a future CL, we should also optimize syncState to not consider draw related state if the task is a dispatch. Also fixes b/234620157 Bug: b/223456677 Change-Id: I8cc969de941f43a2eb66871033d6ec7ddf8b8a66 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3764435 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Lingfeng Yang <lfy@google.com>
Lingfeng Yang 6c418f8c 2022-07-07T14:28:06 Vulkan: __samplerExternal2DY2YEXT-aware TextureVk This CL adds the ability for TextureVk to return an ImageView that is created with a VkSamplerYcbcrConversion object that uses an identity conversion model. This allows direct sampling of YUV values without RGB conversion, which is needed for __samplerExternal2DY2YEXT. Bug: b/223456677 Change-Id: Ie1d4e12375b7808a1f060747bc2d74baeda3fdea Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3751889 Commit-Queue: Lingfeng Yang <lfy@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 1ae7a56c 2022-07-14T13:11:16 Vulkan: Fix double clear of AHBs Originally when deferred clears were implemented, it was assumed that it's impossible at glClear time to have a render pass open without any commends. This assumption was broken under two circumstances: - Clear of 3D attachments that don't include all layers - Clear of AHBs In these cases, the clear immediately opened a render pass with nothing but loadOp=CLEAR. If another clear followed, an assertion would fire. In this change, open render passes without commands are handled such that clears are accumulated in the loadOps. Bug: b/223456677 Change-Id: If99bcf9e24454b0c9e140cb93df7e7f76f175363 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3763169 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Lingfeng Yang <lfy@google.com> Reviewed-by: Lingfeng Yang <lfy@google.com>
Constantine Shablya b47603e0 2022-06-14T05:47:54 Implement GL_NV_read_depth_stencil The implementation will perform two readPixels calls, once for each aspect, and then interleave and pack the result. Bug: angleproject:4688 Change-Id: I46390df893de50b93e855e9333ffab567215a2bb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3702686 Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Cody Northrop <cnorthrop@google.com> Auto-Submit: Constantine Shablya <constantine.shablya@collabora.com>
Yuxin Hu 4c5e9d47 2022-06-21T17:12:56 Do not defer clear if FBO attachment is AHB image When application uses Android Hardware Buffer (AHB) image as the Framebuffer Object (FBO) attachment, it is possible the app doesn't call glReadPixels to fetch the FBO color. In this case deferred clears will not be flushed when the app reads the FBO pixel color, and the app will read the old FBO color. This CL fixes the issue by flushing the glClear calls immediately when any of the FBO color attachments is AHB image. Bug: b/236394768 Bug: angleproject:7458 Change-Id: I9151ab57750007c4ac18af39c3fa4abe752ede5e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3715851 Reviewed-by: Lingfeng Yang <lfy@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi e50351cb 2022-06-10T22:28:58 Vulkan: Don't close render pass on framebuffer fetch For applications that use framebuffer fetch in the same RP as non-fetch programs, we can save some extra RenderPasses by always creating our RP objects with input attachments enabled. This works almost identically except for needing to use the images in a "GENERAL" layout instead of "COLOR_ATTACHMENT_OPTIMAL". According to partners it is possible to achieve performance parity even with GENERAL layout. To remove any potential negative impacts of using the GENERAL layout, the context enters this always-framebuffer-fetch mode only and as soon as a framebuffer fetch program is created. Applications that don't use framebuffer fetch are thus unaffected. This eliminates 20 render passes in the Genshin Impact trace (out of about 58). On a Pixel 6 the resulting benchmark score speeds up by ~25%. For Real Racing 3, the speed up is ~30%. Based on change by jmadill@chromium.org Bug: angleproject:7375 Change-Id: Ib6c73e95d06229f8545d502b388ee2a55a582323 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3697308 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 6d3c6370 2022-06-18T00:13:56 Vulkan: Fix 180 and 270 degree rotated resolve Bug: angleproject:7197 Bug: b/235877059 Change-Id: I4d4ee622f49bb3218449414a1f0dd91fa4e4f541 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3708997 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 72e457fe 2022-06-03T15:36:01 Vulkan: Promptly destroy cached framebuffer when it becomes invalid When Texture gets respecified, the VkFramebuffer cache created out of it becomes invalid and will never possibly get used. Before this CL, we never clear such invalid framebuffer objects from the cache. This CL keeps a reference to the cache key in each attachment and will immediately destroy the cached VkFramebuffer object when one of the attachment has become invalid. Bug: b/234769934 Change-Id: Ib01f6dffe9211084b1ada340081daf905e3f1bef Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3682164 Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi a0b5299b 2022-04-12T00:38:50 Vulkan: Fix resolve with subpass into smaller framebuffer The condition to optimize resolve with subpass did not take into account that the resolve area must match the render pass are, neither did it disallow flipping and rotation. Bug: angleproject:7196 Bug: chromium:1314383 Change-Id: I57e50da4d6e04dfebcce3c0a5061015e5ee8773b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3581055 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Amirali Abdolrashidi 607d398e 2022-03-14T16:32:21 Vulkan: Optimize resolve of multisample swapchains * Resolves the multisampled image if the last render pass draws into the default framebuffer. * Added test to check the number of resolves in the optimization subpass (credit: Xinyi He) * Added test to check the number of resolves outside the subpass. * Added disabled test to see if the subpass resolve works. Bug: angleproject:6762 Change-Id: I86a8db3387851ab97d5f7a3d8a0ff26961254c14 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3523062 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi 256bbb8a 2022-04-04T22:24:55 Vulkan: Don't invalidate resolve attachment except with MSRTT Previously, resolve attachments were only used with MSRTT emulation. As such, when an attachment was invalidated, its corresponding resolve attachment was also invalidated implicitly. This changed when glBlitFramebuffer was optimized to resolve attachments, though the render pass is immediately closed and no chance is currently given to invalidation. An upcoming change needs to invalidate the multisampled attachment independently from the resolve attachment. That is fixed in this change so that the implicit invalidation is done only for MSRTT emulation. Bug: angleproject:6762 Change-Id: Ia730d4bea1f4229c8068a41b151a7af95649b606 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3569483 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 36a051d8 2022-03-28T22:53:38 Vulkan: Move mid-RP color clear to loadOp if content undefined Instead of using vkCmdClearAttachments, if the color attachment has not been written to, modify the loadOp of the currently open renderpass to CLEAR. This is an adaptation of commit cfe5a1735a934cc83133bb6c69d19aa27278a270 The difference with that commit is that, with the prior changes that added tracking of color attachment access in the render pass, this change is greatly simplified by being able to immediately know if clear can be moved to the beginning of the render pass. Bug: angleproject:5048 Change-Id: I72b3613ad08ff869b71aced7e1f4e9be916d7b49 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3557815 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Steven Noonan 1205a7e1 2022-03-24T22:15:44 Vulkan: always respect deferred clears in render pass I had a situation which was like this: - glBindFramebuffer(fbo) - glClear(color + depth) - series of depth-only draws: - glDrawBuffers() - disable all color buffers - glColorMask() - all false - glDrawElements/glDrawArrays - glBindFramebuffer(0) Even though the glClear happened before glDrawBuffers/glColorMask, it only got executed on the first glDraw* call. And since the draw buffers got disabled before it decided to act on the Clear, it thought it couldn't touch the color buffer in the render pass. So it ended up doing: vkCmdClearColorImage() on the color buffer vkCmdBeginRenderPass() with LoadOp C=Load, D=Clear before the draw instead of: vkCmdBeginRenderPass() with LoadOp C=Clear, D=Clear Bug: angleproject:7127 Change-Id: Ibc3b55b0c7815defcf6d711fa876eff43ba29d40 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551298 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 041c4c6d 2022-03-25T16:30:03 Vulkan: Track color attachment usage like D/S in render pass That is in preparation for optimizing mid-render-pass clears, which requires an answer to the following query: "has this color image been read from / written to so far in the render pass?" With this change, a future CL will also be able to optimize color attachment invalidates, which currently break the render pass unconditionally, the same way depth/stencil is optimized. Bug: angleproject:5048 Change-Id: I3d3ee40d8444e6861c06340d5d52b17f5ee895b4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3542989 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Lingfeng Yang <lfy@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 3f331fae 2022-03-22T15:23:38 Vulkan: Dirty bits for depth/stencil access and feedback loop In preparation for doing the same for color, the depth/stencil render pass access and feedback loop modes are now updated with ContextVk dirty bits. This change also fixes clear after read-only depth/stencil feedback loop. The render pass wasn't broken in that case. Bug: angleproject:5048 Change-Id: I40f9b49593f9e6f35f42408e41c9d6267edb375e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3542988 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 20e7bbb7 2022-03-18T17:03:18 Vulkan: Fix invalidate of attachments with emulated format Some image formats may be emulated such that the emulated format has more channels than the original. ANGLE clears the image once so that these extra channels contain valid values, and carefully ensures they are never modified. For swapchain images with such formats, as they are automatically invalidated at the end of the frame, a workaroud was added to make sure they are re-cleared in the beginning of the next frame. This however doesn't fix the issue of glInvalidateFramebuffer resulting in the contents of attachments with such formats to be discarded (even if the following render pass clears it, the contents are invalid in between). This change instead makes sure invalidate of images with emulated formats that have extra channels are handled appropriately: - On IMR hardware, the invalidate is dropped altogether as it provides little to no benefit. - On TBR hardware, a clear is automatically staged on the invalidated image. The latter replaces the workaround that was added to make the following render pass use loadOp=CLEAR, by adding a clear that's respected regardless of what the future usage is. This change also paves the way for a future change where the invalidate of color attachments is tracked in render passes similarly to how depth/stencil currently is. With this change, the image is no longer in an inconsistent state where its contents are considered invalid, even though some channels are meant to remain valid. Bug: angleproject:6860 Change-Id: Iec5b4854dfbe3a0bf93cd5aa82c19fe116065744 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3536389 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill e8ee847d 2022-02-23T12:25:39 Vulkan: Add UpdateDescriptorSetsBuilder. This helper class encapsulates the vkUpdateDescriptorSets caching. As part of the refactor, we switch passing a ContextVk to passing a vk::Context with some mutable variables. This helps encapsulate ContextVk. Since we use the perf counters in many places, this CL moves the perf counters to vk::Context, so we can access them everywhere. Refactoring change only. Bug: angleproject:6776 Change-Id: Id529962b2f425bece6f9b3bd0cd1698c692e58cb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3484980 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill a956162c 2022-03-01T13:05:29 Vulkan: Expose performance counters via extension. This CL rewrites the Vulkan perf counters test to work in the angle_end2end_test suite using the newly exposed AMD extension. Note that we implement only a subset of the extension. Instead of generating monitors and starting/stopping them we simply read back all performance counter data at once using the special montior value "0". The CL also enables these tests on SwiftShader. Bug: angleproject:4918 Change-Id: I5d8f6eecb1ccff448657cbdb65b51a225dfb90c0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3497538 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 5749ec7d 2022-03-01T02:14:42 Revert "Vulkan: Move mid-RP color clear to loadOp if content undefined" This reverts commit cfe5a1735a934cc83133bb6c69d19aa27278a270. Reason for revert: https://bugs.chromium.org/p/angleproject/issues/detail?id=5048#c7 @timvp That change just caused a regression in my project. I clear the color + depth buffer before drawing, but initially draw only to the depth buffer. It seems that it decided to ignore the color buffer clear as a result of that. Original change's description: > Vulkan: Move mid-RP color clear to loadOp if content undefined > > Instead of using vkCmdClearAttachments, if the color attachment has not > been written to, modify the loadOp of the currently open renderpass to > CLEAR. > > Bug: angleproject:5048 > Test: VulkanPerformanceCounterTest.MidRenderpassClear > Change-Id: Ida47e6ac7d0f29e2c49bdf2e74c1d876a5d7c223 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3381912 > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Tim Van Patten <timvp@google.com> Bug: angleproject:5048 Change-Id: Iec5c73632429a80f955f7d659cf670f9cbb6c9b7 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3496662 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten cfe5a173 2022-01-11T19:26:42 Vulkan: Move mid-RP color clear to loadOp if content undefined Instead of using vkCmdClearAttachments, if the color attachment has not been written to, modify the loadOp of the currently open renderpass to CLEAR. Bug: angleproject:5048 Test: VulkanPerformanceCounterTest.MidRenderpassClear Change-Id: Ida47e6ac7d0f29e2c49bdf2e74c1d876a5d7c223 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3381912 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 71d06198 2022-02-07T11:16:41 Vulkan: Fix vkCmdClearAttachments vs multiview Bug: angleproject:6262 Change-Id: I5a24693bb1b35201213c2e3fa25f7864609357b3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3442255 Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 02ad19e3 2022-02-07T13:46:46 Vulkan: Fix vkCmdResolveImage offsets glBlitFramebuffer takes identical regions for src and dst when resolving. vkCmdResolveImage should use the clipped area instead of using the actual offsets passed to this function. Bug: chromium:1292537 Change-Id: I13b91a4e14bdb3fcbf8f01edb36d7fb4110429ea Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3444340 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Cody Northrop 7d7cca47 2022-01-17T18:00:25 Vulkan: Update default FBO when fetch in use If the fetch mode of the default framebuffer changes, lazily create and use a new set of framebuffers (one per swapchain image) that are setup for fetch (i.e. have a matching renderpass). Test: FramebufferFetchES31.DefaultFramebufferTest Test: FramebufferFetchES31.DefaultFramebufferMixedProgramsTest Bug: angleproject:6893 Change-Id: Iff2b73d7c34b9b8ca9429c3f24aa700c2746cc81 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3401933 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Cody Northrop <cnorthrop@google.com>
Shahbaz Youssefi 33427a4b 2022-01-31T12:07:43 Vulkan: Fix vkCmdResolveImage extents The source framebuffer's extents were accidentally used instead of the blit area extents. Bug: chromium:1288020 Change-Id: Ib723db50d9687fee0453d027141a94ea26d8a4b8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3427561 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 9d11a341 2021-12-16T13:47:04 Vulkan: Fix Vulkan SCB vs multiple subpasses vkCmdNextSubpass must be called on the primary command buffer, so the render pass command buffers need to be split on subpass boundaries. This is only done when using Vulkan secondary command buffers. Bug: angleproject:6811 Change-Id: I087fff305c757c78e87bfde4410e7de6bd1a6ba6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3344774 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi acd8fc76 2021-12-16T01:05:02 Vulkan: Distinguish RP and outside-RP command buffer types What goes inside and outside a render pass command buffer is largely mutually exclusive. Moreover, the size and frequency of allocations is different between the two. This change distinguishes the C++ types used for inside and outside render pass command buffers: - The type now documents which command buffer a function is able to receive. - `isRenderPass` flag passing, checking and asserting is largely removed. - A follow up change experiments with using different (Vulkan vs ANGLE) secondary command buffers for inside and outside RP command buffers. - A future change could specialize the pool behaviors per command buffer type. Bug: angleproject:6811 Change-Id: Ia4bc669d26ac7e94e8a0dfb9b361666c82f42cc3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3344373 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 6da1ac81 2021-12-22T10:13:43 Vulkan: Switch ReadPixels from DynamicBuffer to shared pool FramebufferVk::readPixelsImpl() and ImageHelper::copyImageDataToBuffer() use per FramebufferVk DynamicBuffer. This CL removes this and uses shared buffer pool to allocate a temporary staging buffer for readPixels as needed and frees it immediately afterwards. Bug: b/208323792 Change-Id: I65ddf9bf9f1f14578d9def63f5287cb1a4121dff Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3354038 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi c1598640 2021-11-30T23:44:30 Vulkan: Improve mid-RP clear warning message One app does: - Draw - Draw - Clear depth, then disable it - Draw In this case, the message generated for mid-RP clear, suggesting the clear be done earlier is not meaningful as the previous draw calls did use the depth/stencil image. The message now includes an alternative suggestion to invalidate the depth/stencil image instead of clearing it. Note that the app may still legitimately do multiple passes in one render pass where depth/stencil is cleared in between, so the warning is not applicable in all cases. It's still useful to notice issues in more common scenarios. Bug: angleproject:2472 Change-Id: I3abbecf8c83b7b856c2430675e69b1471e91c0c4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3308920 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi cf8ac00a 2021-12-20T11:57:25 Vulkan: Fix MSRTT w.r.t stencil-only unresolve The stencil bit was being silently masked out in a bitset in FramebufferDesc that tracked whether the framebuffer requires any unresolve. If only stencil needs unresolving, this mask was zero, leading to an incorrect framebuffer getting pulled from the cache. A follow up change will add an ASSERT in BitSetT to catch such errors in the future. This issue was only reproducible on SwiftShader and AMD as the only implementers of VK_EXT_shader_stencil_export. Bug: angleproject:6840 Bug: angleproject:6324 Change-Id: I4f055982ebd75f621ec1e34b0d60eaa497c27b17 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3349979 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 55840e90 2021-12-03T15:24:00 Vulkan: Fix deferred flush vs UtilsVk Take the following scenario: 1. Draw 2. Flush (this is deferred) 3. Get image view (this is retain()ed) 4. Pass view to a draw-based UtilsVk function 5. Flush 6. Delete image view At step 4, UtilsVk may start a new render pass and use the image view from step 3. Since the flush at step 2 is deferred, it will be performed at this step, and so the serial of the image view is set to the previous submission. When step 4 uses this view, it doesn't retain it. Step 5 submits the new command buffer using this image view. At step 6, if the previous submission has finished, it will destroy the view immediately even though it's in use by the new submission. One solution could have been to make sure render pass closure originating from UtilsVk doesn't incur a flush. However, due to the current design where the render pass is immediately recorded in RendererVk's primary command buffer, it's possible that an unrelated context would perform the flush anyway. This change makes sure instead that the render pass is closed before any views are allocated/retained to be used by UtilsVk. Bug: chromium:1272266 Change-Id: I5bdefb34e03c368511c4c174cf7965fda158d2b8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3315976 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi dbc0c646 2021-11-06T01:09:26 Vulkan: Output the reason for RP closure in command buffer To make it easier when viewing the command buffer in a graphics debugger, this change inserts a marker just before closing the render pass that specifies why the render pass was closed. Bug: angleproject:2472 Change-Id: I862e500cd58332d6e199c853315c560fe6a73dc2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3265609 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi d2d3a546 2021-11-11T12:22:04 Vulkan: Write perf warnings in command buffer It's much easier to understand what command the perf warning refers to when it's visible in the command buffer using a graphics API debugger. This change creates ANGLE_VK_PERF_WARNING which gives the warning both to the application (through ANGLE_PERF_WARNING) and inserts it in the command buffer. Bug: angleproject:2472 Change-Id: Ie84feed53eca5cda93e1f2bc653fcbf9bcd57b56 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3275839 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Brandon Schade 2aa62964 2021-11-11T13:24:27 Vulkan: Reset mFramebuffer when mFramebufferCache is cleared The mFramebuffer pointer becomes stale when mFramebufferCache is cleared. Set mFramebuffer to nullptr when this happens. Test: --deqp-surface-type=fbo --deqp-case=KHR-GLES31.* Bug: angleproject:6682 Change-Id: I5fd21a64f0f935de04e2934e794c915ccf880c16 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3276701 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Mohan Maiya <m.maiya@samsung.com> Commit-Queue: Brandon Schade <b.schade@samsung.com>
Shahbaz Youssefi ef93b32c 2021-11-09T00:26:13 Vulkan: Fix deferred clears vs invalidate In this scenario: - Clear color - Invalidate depth - Clear color The invalidate step flushed the deferred color clear, but the following clear did not expect an open render pass without any draw calls in it. This change fixes this issue, while simultaneously optimizing invalidate by making sure the clears accumulated during syncState() are redeferred instead of flushed. This issue was discovered in https://chromium-review.googlesource.com/c/angle/angle/+/3266176 where, as part of an unrelated fix, an accidental render pass closure is removed. Bug: chromium:1267424 Change-Id: Icfc0a53dbf84e6339ee23960ed847444830054e6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3266178 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 3a9f18f1 2021-10-18T10:44:38 Refactor program pipeline handling. In preparation for moving more code from gl::Program to gl::ProgramExecutable so it can be shared with ProgramPipeline. Bug: angleproject:6566 Change-Id: Icb7ecccb37ae8e0d7d5fef8968f0dd7ef6fe6150 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3226305 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill aac5d678 2021-10-20T11:48:57 Make "isCompute" private to ProgramExecutable. This eliminates uses of "isCompute" is the Vulkan back-end. Instead of checking the state flag, we can use the context of the current command to determine if we're running a compute or a graphics command. This will eventually lead to us being able to compile the program pipeline objects before we run a draw or dispatch command. Changes the driver uniforms descriptor desc to bind to both graphics and compute shader stages to simplify the code. This could have theoretical but low-risk performance implications. Bug: angleproject:6595 Change-Id: Ie30d419b6ece5b33f5066a034d3805fe96519b36 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3233903 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi e637e4c9 2021-10-18T13:54:00 Vulkan: Optimize updating blend state in pipeline desc Updating blend funcs and equations always updated all 8 slots. Now that's only done for the attachments that are present. Bug: angleproject:6298 Change-Id: I58fa7e4dfa27d05fef54cc9d56c7b2aa5ef43dd8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3202550 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Charlie Lao 6cb599f9 2021-10-06T13:07:27 Vulkan: Change dest to dst for consistency Cleanup only, no functional change. dst aligns better with src. Bug: angleproject:6502 Change-Id: I69821b1aae50a7ce647c7cc876468b6de309eec8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3208514 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com>
Shahbaz Youssefi 4ad55d07 2021-10-05T15:45:05 Vulkan: Turn 1-view multiview FBOs into no-multiview When only 1 view is enabled, ANGLE continued to append a VkRenderPassMultiviewCreateInfo struct to the render pass. VVL produced an error when transform feedback was used in this case, quoting that multiview and transform feedback cannot mix. This change makes sure that 1-view framebuffers are threated as if they were not multiview. Bug: angleproject:6478 Change-Id: If079c9a052f822342a49a9cc880be2577a356b64 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3206269 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi eb1d5ca5 2021-01-29T15:34:49 Vulkan: Enable sync validation Based on a change by tobine@google.com Bug: angleproject:5290 Change-Id: Ieae1be5a29f0dcb3ea8aaa04e77fc402380a08b1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3171432 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 371542cd 2021-08-23T23:10:09 Vulkan: Use VK_EXT_load_store_op_none With read-only depth/stencil attachments, ANGLE utilizes storeOp=NONE to optimize memory bandwidth (by avoiding write back of tile memory at the end of the render pass). Simultaneoulsy, this avoids a synchronization hazard with the next write to that depth/stencil image. If a framebuffer contains a depth/stencil attachment but it's unused, ANGLE utilizes loadOp=NONE/storeOp=NONE to effectively remove any memory bandwidth wasted on the attachment. Bug: angleproject:5371 Change-Id: I76cbadbf1194041532ac4b690ffe087298f2de51 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3114232 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 8ea87a67 2021-08-17T18:46:36 Vulkan: Avoid texture format fallback when possible Some texture formats are not renderable on some hardware. For example, R4G4B4A4 are not renderable on nvidia and not blendable on ARM. R5G5B5A1 are also not blendable on nvidia. Right now when we generate format table, we are being most conservative, picking an actual format that is always renderable and blendable. This means when R4G4B4A4 is used on one of these GPUs, we are always falling back to R8G8B8A8 regardless if the texture is actually being used as color attachment or not. This CL adds a actualRenderableImageFormatID field in vk::Format. Initially we will pick actualImageFormatID which only ensures texture sample capability. If later on the texture is being attached to FBO, then we will switch to actualRenderableImageFormatID and do data copy if necessary. This way we save memory and reduce texture bandwidth for most usage of these textures. For renderBuffer and surfaces and EGLImages, we always pick the renderable textures. Bug: b/196456356 Change-Id: I02eec3365c2a317b0d1bad6dbdc3e741114c5bba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3104514 Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 6977fa6f 2021-08-31T09:47:59 Vulkan: Store actualFormatID (not intendedFormat) in RenderPassDesc Today we store intendedFormatID in the RenderPassDesc. At unpack time, we convert intendedFormatID to vk::Format and then get the actual VkFormat. This is a bit complex and unnecessarily confusing. And this will be very error prone in the future when vk::Format has two actual image formats. This CL packed actualFormatID into RenderPassDesc and converts to VkFormat directly. Once packed in the RenderPassDesc, we never needs to reference to intendedFormat or vk::Format since all these does not matter. The only format matters is actualFormatID once you packed into the RenderPassDesc. This simplifies the logic and prepare for the future CLs. Bug: b/196456356 Change-Id: Ia282115c824e3ec446d2be15b40b1e2974b99afa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3133761 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Tim Van Patten 6eeab192 2021-08-27T16:26:25 Vulkan: Don't defer clear for read render target We shouldn't collect deferred clears for the read render target because they get applied to the draw render target. This CL flushes stages updates to the read render target only if it's not the same as the draw render target. This can happen when the read render target is bound to another surface. Bug: b/192327017 Change-Id: I7c9e804f4eff10728aed7aeeaf41ef3869c9bdbd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3125462 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Charlie Lao e98539f0 2021-08-17T14:42:26 Vulkan: Add ImageHelper::getIntendedFormatID() This adds helper API to return intendedFormat directly from ImageHelper object instead of vk::Format, to make API symmetrical. It is also necessary. It is also needed in some places where we no longer have access to vk::Format any more due to refactoring. Bug: b/196456356 Change-Id: Ie0502793623138ded28c3f01320c57ffea2d93df Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3101925 Reviewed-by: Ian Elliott <ianelliott@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 cf24931a 2021-08-17T10:48:23 Vulkan: Add ImageHelper::getActualFormat() This is preparation for future CLs. In the future vk::Format may not tell you what actual format is. This CL adds a new method of ImageHelper::getActualFormatID() and ImageHelper::getActualFormat() so that we can use these two APIs and avoid using vk::Format, thus reduce reliance on vk::Format. Bug: b/196456356 Change-Id: Ic50e664e033feb5e066f40269c33cffe96024172 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3100319 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Jason Macnak 0be285c6 2021-07-20T11:36:22 Vulkan: Flush read RT if color attachment is the read buffer Prior to this change, the following sequence: * eglMakeCurrent(..., draw=surface1, read=surface1, ...); * glClear(...); * eglMakeCurrent(..., draw=surface2, read=surface1, ...); * glBlitFramebuffer(...); * eglMakeCurrent(..., draw=surface1, read=surface1, ...); * glReadPixels(...); would end up with the `vkCmdClearColorImage()` on surface1 occuring after the `vkCmdBlitImage()`. This CL updates flushColorAttachmentUpdates() to flush any staged updates to both the read and draw attachments, since they can be different if different read and draw surfaces are bound. Adds a test which is a small repro of android.opengl.cts.FramebufferTest#testBlitFramebuffer failure. Bug: b/192327017 Test: EGLSurfaceTest.BlitBetweenSurfaces/* Change-Id: Iabad26dfcd8633e9dcfcee2fb16ba352bc3931d5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3078980 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Shahbaz Youssefi cf090996 2021-08-05T16:20:39 Vulkan: Call onFramebufferChange from a single place When sRGB control mode was dirty, onFramebufferChange was called which may not have been necessary if the actualy state hadn't changed. This removes a call to onFramebufferChange() in this path, and leaves it to be naturally called if the framebuffer desc actually changes. Bug: angleproject:5075 Change-Id: I177572a3cb819d7e1ecd589f46e03da4b967529e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3076619 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 5b314268 2021-06-15T17:37:45 Vulkan: Support OVR_multiview and OVR_multiview2 Multiview is supported in Vulkan simply by specifying the number of views in the render pass, and creating the appropriate image views. A number of changes to the way image views and render targets are stored are made to support those that don't cover the entire range of layers. One particular detail that is not implemented in this change is the use of queries in combination with multiview. Vulkan specifies that N queries are actually produced (N being the number of views) which must be summed by the application, but this is not currently done. Bug: angleproject:6048 Change-Id: I1d4a9894c232d3a93d7a97c9fa0eedc334e57469 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2967625 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Ian Elliott ebf75698 2021-06-10T18:55:04 Vulkan: Fix AGI clear hierarchy bug for clear commands This approach properly handles outside-render-pass clears. Bug: b/190622922 Change-Id: Ia4a9d6ec13d7da8c4a445af1127e82c03f37e8b2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2951960 Reviewed-by: Mark Lobodzinski <mark@lunarg.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Ian Elliott <ianelliott@google.com>
Mark Lobodzinski 4bafc503 2021-06-01T10:59:17 Vulkan: Fix AGI hierarchy for clear commands Treat mid-render-pass glClear* commands the same as glDraw* commands, generating a hierarchy. This results in vkCmdClearAttachment commands being nested under glClear, instead of being a peer of glDraw* commands. Bug: b/183547523 Change-Id: Ibc6900b0485fd174d79c8fe6c94ea17dbefa520b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2941364 Reviewed-by: Mark Lobodzinski <mark@lunarg.com> Reviewed-by: Mike Schuchardt <mikes@lunarg.com> Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi bcb678a5 2021-05-27T16:50:55 Vulkan: Fix deferred clears vs 3D textures Two bugs are fixed in this change. One is that framebuffer attachments to 3D textures should not attempt to defer clears. The clear staged for the 3D texture applies to all slices, not just the slice the framebuffer is attached to (and that would get cleared through deferred clears). Secondly, when clearing an attachment to a 3D texture, the clear must be applied immediately through a render pass loadOp to affect only the slice that's attached. This was already handled for layered framebuffers where the clear was applied immediately if the 3D texture render target had more layers than the framebuffer. The condition for this is generalized to check whether the 3D texture has more slices (regardless of whether the render target is layered or not). Test is based on one written by Austin Eng <enga@chromium.org> Bug: angleproject:5967 Change-Id: I43cf5fc24673323eda8390021641e2238be6e375 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2923785 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Geoff Lang bccb0d56 2021-05-11T13:53:05 Add messages for framebuffer completeness errors. This also creates a common code path for all framebuffer completeness errors (FramebufferStatus::Incomplete) which helps for adding a debug breakpoint. Bug: angleproject:5949 Change-Id: Ib102dbf86e020777e56c6dc6b78dda8ebdba2127 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2888110 Commit-Queue: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0