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

src/libANGLE/renderer/vulkan/FramebufferVk.h

Log

Author Commit Date CI Message
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>
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>
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>
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>
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>
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>
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>
Charlie Lao d655ad29 2022-05-31T14:20:16 Vulkan: Add tests for FramebufferCache growth bugs When texture attached to FBO gets respecified, we shouldn't keep growing FramebufferCache. When texture attached to fbo get glTexParameteri(GL_TEXTURE_SWIZZLE_R) call with the same value, we should also not destroy/recreate framebuffers (in fact should not recreate VkImageView). We ran into this usage pattern on surfaceflinger. When texture attached to fbo get glTexParameteri(GL_TEXTURE_SWIZZLE_R) call with different value, we should also not destroy/recreate framebuffers (in fact should not recreate VkImageView). We ran into this usage pattern on surfaceflinger. Bug: b/234769934 Bug: b/234602034 Change-Id: I9fc881486f95cc3da843f50fa0a8cdcbfd4fc625 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3681081 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
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 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>
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>
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 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>
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>
Shahbaz Youssefi d1462228 2021-03-09T11:25:36 Vulkan: Use VK_EXT_multisampled_render_to_single_sampled Additionally, makes the emulation path not require independentResolveNone. This was only used to select the NONE resolve mode when the attachment format doesn't have either of depth or stencil aspects, but it's ok to specify the same resolve mode for both aspects even if one aspect is missing. Bug: chromium:1088005 Change-Id: Ifc37cbf5331145179c5927853b996a0d62b871ee Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2743666 Reviewed-by: David Reveman <reveman@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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 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>
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>
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>
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 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>
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 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 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>
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 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 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>
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>
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>
Tim Van Patten e78d9a61 2020-07-24T11:58:45 Convert unordered_map to absl::flat_hash_map for select files This is the initial CL to start migrating to abseil in various places: - formatutils.h - FramebufferVk.h - Program.h - ProgramExecutableVk.h - RewriteRowMajorMatrices.cpp This intentionally hits a couple different places in the code to make sure the abseil dependencies are added to the required targets. Bug: angleproject:4873 Change-Id: Idd6084dff2ebce47833f304c605bbf3151b97414 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2402382 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.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 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 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>
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>
Jamie Madill 8d412db2 2020-08-29T22:25:18 Revert "Convert unordered_map to absl::flat_hash_map for select files" This reverts commit 1acaf4eced42a26f09b4d9180a9e5db0f37bc9a4. Reason for revert: Fails when is_component_build is not set: lld-link: error: <root>: undefined symbol: public: __cdecl absl::Condition::Condition<struct std::__1::atomic<bool> const>(bool (__cdecl *)(struct std::__1::atomic<bool> const *), struct std::__1::atomic<bool> const *) <snip> Original change's description: > Convert unordered_map to absl::flat_hash_map for select files > > This is the initial CL to start migrating to abseil in various places: > - formatutils.h > - FramebufferVk.h > - Program.h > - ProgramExecutableVk.h > - RewriteRowMajorMatrices.cpp > > This intentionally hits a couple different places in the code to make > sure the abseil dependencies are added to the required targets. > > Bug: angleproject:4873 > Change-Id: I68c7d067b6912b0cc0ecde231501dbed92f0b189 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2321735 > Commit-Queue: Tim Van Patten <timvp@google.com> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Charlie Lao <cclao@google.com> TBR=timvp@google.com,jmadill@chromium.org,cclao@google.com Change-Id: I75041532fc5126b4c7cc5e0d4529883fb357e05b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: angleproject:4873 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2383870 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tim Van Patten 1acaf4ec 2020-07-24T11:58:45 Convert unordered_map to absl::flat_hash_map for select files This is the initial CL to start migrating to abseil in various places: - formatutils.h - FramebufferVk.h - Program.h - ProgramExecutableVk.h - RewriteRowMajorMatrices.cpp This intentionally hits a couple different places in the code to make sure the abseil dependencies are added to the required targets. Bug: angleproject:4873 Change-Id: I68c7d067b6912b0cc0ecde231501dbed92f0b189 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2321735 Commit-Queue: 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>
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 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 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>
Shahbaz Youssefi dcc56215 2020-07-19T01:12:09 Vulkan: Implement GL_EXT_multisampled_render_to_texture This change allows the use of resolve attachments in the Vulkan backend. GL_EXT_multisampled_render_to_texture is implemented using this feature. The infrastructure for specifying resolve attachments is designed with eventual support for GL_EXT_multisampled_render_to_texture2 in mind as well as optimizations to glBlitFramebuffer() and multisampled backbuffers. Proper support for glRenderbufferStorageMultisampledEXT is still missing from this change. All tests use this for the depth/stencil attachment and don't read back the data. Currently, the depth/stencil attachment is created as a normal multisampled image. Bug: angleproject:4836 Change-Id: I110a7f63312ae61a657b6094adf7d97c92bd5843 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2304170 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 68791f89 2020-07-20T17:42:23 Vulkan: Fix sub invalidate marking render targets undefined When glInvalidateSubFramebuffer is called, the framebuffer is only partially invalidated. FramebufferVk::invalidateImpl was nevertheless marking the render targets as undefined, which would lead the subsequent render pass have loadOp=DONT_CARE. This is not correct, as the rest of the framebuffer is expected to still be valid. Bug: angleproject:4859 Change-Id: I2e64baa32b1fc84beb8008411b564cd7619af962 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2309111 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Courtney Goeltzenleuchter 93eb633c 2020-07-07T15:41:38 Inline depth/stencil clear if in middle of renderpass Some apps have a pattern where they clear the depth & stencil buffers in the middle of the frame which causes the Vulkan backend to stop the existing render pass and start a new one. This causes more loads & stores of buffer contents than if we inline that clear with a draw. Bug: b/159808300 Bug: angleproject:4695 Change-Id: I7a15af22f47a81051fa33fa19eaa123d8b66597c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2289945 Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Ian Elliott 7e2a9820 2020-07-20T12:38:05 Vulkan: Make explicitly-[non-]rotated get methods Split FramebufferVk::getCompleteRenderArea() into 2, [non-]rotated, explicitly-named methods. Simplify the uses of these methods, and fix some rotation cases. Also explicitly-name FramebufferVk::getScissoredRenderArea(). Bug: b/151111296 Change-Id: I1754ec2796fd8625b916a2dba2e723e70ecba419 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2305389 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Manh Nguyen d4874cb3 2020-06-25T10:49:32 Reformat Framebuffer::readPixels Reformat Framebuffer::readPixels and its overriding methods to the following method signature angle::Result readPixels(const Context *context, const Rectangle &area, GLenum format, GLenum type, const PixelPackState &pack, Buffer *packBuffer void *pixels); This will allow capture replay tool to use its own PixelPackState to read pixels from framebuffer without having to set the global states Bug: angleproject:4787 Change-Id: Idc64179d8e8f6b5163ef0747f239cd5172a2491b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2267417 Commit-Queue: Manh Nguyen <nguyenmh@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill d705f18f 2020-05-11T13:53:13 Vulkan: Add immediate scissored clears. This allows us to avoid using draw commands with pipelines for scissored clears. This prevents some tests from generating large numbers of VkPipelines. Bug: angleproject:4517 Bug: angleproject:4617 Change-Id: Id4a44000078098a60aa89233cfef30b75727d108 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2194473 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill d657e1d7 2020-04-24T13:13:18 Vulkan: Defer framebuffer clears. This works by storing the deferred clears in the ImageHelper's staging buffers. We apply the deferred clears onto the RenderPass right before we begin to draw. Storing the clears in the ImageHelper solves problems where we clear GL Textures in a Framebuffer and then unbind the Textures and sample from them. Or do other commands like CopyTexImage. Note that because the staging buffer clears only handle full-image clears we need to immediately apply some scissored clears where before we would use the RP. This should be a pretty rare occurrence and it is possible to optimize that in the future. Reduces the RenderPass count in the Manhattan "frame 10" trace from max 22 to max 20. May improve perf slightly on Android or may have effects too small to measure. Should not regress performance. Bug: angleproject:4517 Change-Id: I02150d531022afb903f1058f070937ec6337bd88 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2142711 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Charlie Lao 54a3d7cb 2020-04-20T12:02:02 Vulkan: Use DontCare for the presentable surface's last renderpass depth/stencil storeOp The EGL spec says depth/stencil value are undefined after swap. We dont need to store depth/stencil value if this is the very last renderpass of a presentable surface and the endRenderpass call is from swap call. Bug: b/153885625 Change-Id: Ie853d2686c8eb15a4fa9dbdd80eb66e9fc037d24 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2157886 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Jamie Madill 1033d55d 2020-04-07T14:01:24 Pass binding enum to Framebuffer::syncState. Will allow us to determine if we're clearing the read or draw FBO. Then we can stash clears for the draw FBO only and issue them immediately for the read FBO in the Vulkan back-end. Bug: angleproject:4517 Change-Id: Ifc043317d6156a75749b13f9d2c44a17e14ee378 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2139997 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill c916fe8a 2020-04-02T16:57:49 Don't call syncState inside FBO queries. This prevents a syncState ordering issue that was confusing FBO sync when robust resource init is enabled. Also cleans up some redundant format processing for the half float extensions. Bug: angleproject:4517 Change-Id: Ieb13fc5203cf824a3e8affda96ea5cbbd89d78ee Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2134411 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Alexis Hetu b83b0f5e 2020-01-31T15:09:17 Add support for NV_read_depth, NV_read_stencil and NV_depth_buffer_float2 extensions This cl adds the ability for the ReadPixels function to read other attachments than the color attachment. Checks were added for both depth and stencil attachments. A new test was added (DepthStencilFormatsTest.DepthStencilReadback) to test this new functionality. As the name mentions, it's used to test reading from the depth and stencil attachments using ReadPixels. Bug: angleproject:4295 Change-Id: I6fe9be11f05d6055a5883b4315f870e7c0ac41ad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2031702 Commit-Queue: Alexis Hétu <sugoi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill d03b15b2 2020-03-26T17:22:18 Vulkan: Mask out Depth/Stencil RTs in feedback loops. This should enable some cases of limited support for feedback loops with depth/stencil buffers. For example with Manhattan and the Vulkan back-end. Increases the number of RenderPasses in Manhattan slightly. This will regress performance slightly until we can work out a better solution that is also conformant with the spec. Bug: angleproject:4517 Change-Id: I2758e6b4c2a930474c09cdc0950f3b6c34541089 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2106670 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill 4fb3c28f 2020-03-19T19:10:45 Vulkan: Fix Framebuffer cache depth/stencil issue. The DrawBuffers resetting logic didn't update the depth/stencil serial. Fix this and add a regression test that would crash in this situation. Note that the Manhattan benchmark could trigger this under some cases. Bug: angleproject:4322 Bug: angleproject:4490 Change-Id: Ie4b24efeb5991ecaa85bf8f964f77476bd6f167d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2111333 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com>
Jamie Madill 9d812d35 2020-03-18T15:31:14 Vulkan: Remove public FramebufferVk::getFramebuffer. Goal: enable rendering feedback loop detection for Manhattan. Making getFramebuffer private prevents direct access to the Framebuffer internals. Hiding access lets the FramebufferVk class switch up its implementation to support different VkFramebuffers for feedback loop cases. Also this is a general code cleanup. Bug: angleproject:4490 Change-Id: Ib4f5e34d476ccd8fc43a1adb031933ab347ca7b7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2109333 Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill a741abb9 2020-02-21T16:37:37 Vulkan: Rename CommandGraphResource to Resource. Also renames the h and cpp files to ResourceVk (to keep distinct from other resource.h/cpp files) and renames 'onResourceAccess' to 'retain'. Cleans up a few remaining mentions of the command graph in comments. Bug: angleproject:4029 Change-Id: Ifc8e880c8cea3fc48a4aec4730191c88aa35a076 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2065920 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill c58458e6 2020-02-19T14:51:41 Vulkan: Remove CommandGraph code. Also updates relevant comments to no longer refer to a graph. Bug: angleproject:4029 Change-Id: Ic29716e9ae4926870f902947d49d8fee7af98662 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2057804 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Tobin Ehlis cf2ec3b1 2020-01-31T16:55:50 Vulkan:Add FramebufferVk cache This adds a FramebufferVk cache. Cache signature is based on unique Serial values that are assigned to ImageHelper objects backing all color and DS rendertargets as well as level/layer values unique to the imageView. Update the Serials and cache signature at FramebufferVk::syncState() time. L0 cache is a currently active framebuffer. L1 cache retrieves previously created framebuffer from new cache. If neither of those hit, create new FramebufferVk and add to L1. Bug: angleproject:4322 Change-Id: I3f585271798ddfb9e5f194020adca8cf8a6b19dd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2033869 Commit-Queue: Tobin Ehlis <tobine@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill a61e273a 2020-02-19T14:51:40 Vulkan: Fix store ops with linear command recording. DiscardFramebuffer was being ignored in the new linear path. Fix this by using the correct APIs. Also cleans up some of the access to the "RenderPassCommandBuffer" struct in ContextVk. Add a new accessor that returns the RenderPass without a flush that ensures it is only called when a RenderPass is already started. Bug: angleproject:4029 Change-Id: Ibd199f3a371c0f91b448a0b34c8752dc8b76c284 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2057329 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 20b1259a 2020-02-05T17:08:05 Vulkan: Command graph linearization (Step 2). ES 2.0 is feature complete. Passes all of the angle_end2end_tests with the new linear command recording method. Also runs the T-Rex benchmark without any obvious glitches. Likely has issues with creating too many RenderPasses. ES3 is mostly untouched. Bug: angleproject:4029 Change-Id: Ic5acf3d768495fbffd07b07bf0a6f2b5787c51f8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2012900 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 4ff1651e 2020-01-16T12:42:27 Vulkan: Add ResourceUseList helper. This abstracts away the ResourceUse tracking from CommandGraph. Pulling it out will allow us to more easily swap resource use tracking into ContextVk. The command graph is eventually going away so we need to move functionality out of CommandGraph. Bug: angleproject:4029 Change-Id: Icc3bcc824510b03e91f8ff010a82751a81516bfa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2002930 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill b540da89 2019-09-19T14:19:12 Vulkan: Use ResourceUse to track object lifetime. With the new resource tracking scheme the CommandGraph, tracking a "Context serial" aka "current" serial is no longer necessary for CommandGraphResources. Serial tracking has been moved to the shared ResourceUse struct that gets updated on a command submission. Thus we don't need to store the serial as a current separate piece of info in BufferHelper/ImageHelper. Will lead to further redesign for the multi-threading support for Vulkan. Bug: angleproject:2464 Change-Id: I1ae4bcc27fcfb93422b4ab4c9682a458e482f295 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1785990 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill d7f28aae 2019-09-19T14:19:10 Vulkan: Pass CommandGraph when updating serials. This is in preparation for storing a pointer to a shared resource use structure. Bug: angleproject:2464 Change-Id: I8f4ba1c71de6ad6a27ac06fc8012a0e94267cc16 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1785988 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tim Van Patten 56ba54cc 2019-08-08T13:03:34 Support separate read and draw surfaces in eglMakeCurrent Update ANGLE's default framebuffer implementation to support reading and writing to different surfaces within the same framebuffer. Bug: angleproject:2620 Test: EGLSurfaceTest[3] Change-Id: I4b1ea04ca87a751f80cf190bf3adec148fc4fce3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1744746 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Shahbaz Youssefi da904484 2019-07-02T10:49:14 Vulkan: Implement glInvalidate[Sub]Framebuffer Additionally, fixes an issue where the read framebuffer was affecting the render pass desc given to the pipeline. This fix is included with this CL as its test depends on glInvalidateFramebuffer. This issue was revealed by 071d2a44 changing the order in which read and draw framebuffers were synced. Previously, read was synced first, dirtying the pipeline and then draw was synced fixing it. With the order reversed, the read framebuffer is the last to changes the pipeline, leaving it in an invalid state. Bug: angleproject:3201 Bug: angleproject:3202 Change-Id: Ibebf732a3e3cc081e4865f79dcbaedb467fd9038 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1682468 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 7f2520f1 2019-06-26T11:18:33 Vulkan: Refactor DynamicBuffer::init. This will allow us to more easily create a white box test that sets a very small initial size for a dynamic buffer. Bug: angleproject:3082 Change-Id: Ic02bbee83ee8e0f4bfe182e9448c2ce60dea66d5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1667645 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tobin Ehlis <tobine@google.com>
Shahbaz Youssefi b407e1a0 2019-06-03T17:15:51 Vulkan: implement ES3 blit Augment the resolve shaders to be able to stretch and blit too. The UtilsVk resolve function is accordingly expanded to include blit. Bug: angleproject:3200 Change-Id: I30b172a5e388089735ab494f55cbfdc2781a8bf9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1635753 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Shahbaz Youssefi de70a713 2019-06-03T17:05:16 Vulkan: Rename Resolve* shaders to BlitResolve In preparation for adding blit functionality. Bug: angleproject:3200 Change-Id: I77b6b6cbe90b26ee23c25edebaa2b130f3c2987a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1641626 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi f2a1c384 2019-05-21T16:32:49 Vulkan: Implement multisampled framebuffers Simultaneously implements ANGLE_framebuffer_multisample and ES3 multisampled framebuffers. Additionally, implements ES3 framebuffer blitting where multisampled framebuffers are involved. Bug: angleproject:3203 Bug: angleproject:3204 Bug: angleproject:3200 Change-Id: I5694a30f71168e807688a9568e3742b81d907918 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1622667 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Jamie Madill 6722009e 2019-05-20T11:12:53 Vulkan: Handle dirty RTs with state messages. Prior to this CL we were handling dirty state change notifications by flushing the RT Images just prior to use or just after they were changed. This could lead to a few redundant checks in several places. It also meant we needed an owner pointer from the RT to the parent Image. This pointer would be null for Surfaces and Renderbuffers. This cleans up the image flushing logic to be handled by dirty bit notifications. When an app updates an attached Texture with TexSubImage or related calls it will send a notification to the Framebuffer. The Framebuffer then sets a dirty contents bit that is handled in the implementation. In Vulkan this means flushing the dirty bits. Requires adding a flag to the FramebufferImpl class to determine if we need to syncState before we checkStatus. Adding the option allows us to only call syncState for the GL back-end. Not calling syncState allows the robust resource init operation to happen *before* we syncState. Which in turn allows FramebuffeVk to initialize the VkImages in one go. Added new regression tests for Texture updates. This might not cover all cases. I found it was very hard to trigger some of the resource update staging in TextureVk. Bug: angleproject:3427 Change-Id: Idfa177436ba7fcb9d398f2b67922e085f778f82a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1601552 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 2249d4a7 2019-04-05T16:48:55 Vulkan: remove clear depth ability from clearWithDraw This partially reverts the following change: 60ec8f576 Vulkan: break dependency to the depthClamp feature The feature is no longer necessary, and simplifies the usage of utility shaders. Bug: angleproject:2361 Change-Id: I1e87ac8d2517c5a3b50e3d0cddd55c852e0e3e7d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1555313 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tobin Ehlis <tobine@google.com>
Shahbaz Youssefi 127990f9 2019-04-04T13:52:04 Vulkan: Use render pass loadOp for scissored clears At this point, every clear is done through render pass loadOp, except masked color or stencil clears. The only fallback is clearWithDraw, that can clear both color and stencil at the same time. Bug: angleproject:2361 Change-Id: I805fc12475e832ad2f573f665cdfeb766e61a6d0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1553740 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tobin Ehlis <tobine@google.com>
Shahbaz Youssefi f6c937f8 2019-04-02T17:04:08 Vulkan: fix masked stencil clear Previously, masked stencil clear was done by clearing every stencil bit to the ClearValue & Mask. The correct behavior as implemented in this change is to clear only the bits that are set in Mask. This can only be done through a draw call, with ClearValue as the stencil reference, and Mask as the stencil write mask. Note: this change relies on the depthClamp Vulkan feature which is not available on ARM. Bug: angleproject:3241 Change-Id: I0a181c32f881ee813f144e7bdd6f42c8ea6f1966 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1548442 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tobin Ehlis <tobine@google.com>
Shahbaz Youssefi db4ed317 2019-03-29T00:32:45 Vulkan: glClearBuffer* implementation Refactors FramebufferVk::clear such that specific render targets could be cleared, with clear values not necessarily set through glClearColor etc. FramebufferVk::clearWithRenderPassOp is modified so that loadOp and clear values are set after the render pass has been registered in the graph. This allows multiple glClearBuffer calls to coalesce into the same render pass. glClearBuffer calls are then implemented simply as calls to the refactored clear function with the appropriate parameters. Bug: angleproject:3187 Change-Id: I2fdfcbea5bf244f63ec981b91caca47f5ee3cd3a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1545204 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi 0c128e15 2019-03-25T23:50:14 Vulkan: Use render pass ops to clear images when possible On tiling GPUs, render pass loadOp and stencilLoadOp can be used to very cheaply clear an image as it is being render to. This change uses this feature to clear render targets when possible. Bug: angleproject:2361 Change-Id: Ic4bdc908873f4802760d549f4893f84a47beac0f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1500576 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 6854940d 2019-03-25T23:30:49 Vulkan: Correct RenderTargetVk extents to image mip RenderTargetVk::getImageExtents() was always returning the base level extents of the image it was viewing. This resulted in incorrect extents being provided to various framebuffer- and renderpass-related declarations. The function is renamed to `getExtents()` and returns the appropriate mip extents. Bug: angleproject:2361 Change-Id: I059a8d19fcb140c9095107d935aa3e5cb1852fc2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1537327 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0