src/libANGLE/renderer/vulkan/vk_renderer.h


Log

Author Commit Date CI Message
Shahbaz Youssefi f7620039 2024-07-10T10:21:11 Vulkan: Prepare syncval suppressions for dynamic rendering Removing mentions of vkCmdBeginRenderPass and such. Bug: angleproject:42267038 Change-Id: Ibba2c15249b154fb11b116ef75ee6f20e08e4d00 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691343 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 7d461b21 2024-07-10T14:11:53 Revert "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]" This reverts commit c379ff48043a47e444c388c45270db40d3172d50. Reason for revert: Regresses CPU perf and memory when _not_ using DR Original change's description: > Vulkan: Use VK_KHR_dynamic_rendering[_local_read] > > Bug: angleproject:42267038 > Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155 > Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> > Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> > Reviewed-by: Charlie Lao <cclao@google.com> Bug: angleproject:42267038 Change-Id: I3865f0d86813f0eeb9085a92875a33bd449b907f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691337 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi c379ff48 2024-06-10T22:01:57 Vulkan: Use VK_KHR_dynamic_rendering[_local_read] Bug: angleproject:42267038 Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Mark Lobodzinski 3813e805 2024-06-21T14:29:55 Add env var/property control of API dump layer Layer is now included with all debug/assert builds or when specified through GN arg. VK_VULKAN_API_DUMP_LAYER on desktop, or for android set debug.angle.enable_vulkan_api_dump_layer to 1. Also included some renaming since layers other than validation are supported. Bug: angleproject:8623 Change-Id: I2bb976dede53712f781a531d0c4f3ce4d33f052c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5649937 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Mark Łobodziński <mark@lunarg.com> Reviewed-by: Cody Northrop <cnorthrop@google.com>
Amirali Abdolrashidi 05801537 2024-06-13T13:35:05 Vulkan: Add feature for coherent blend advanced op This change will add features that will be used in the follow-up CL. * Added the following feature to the Vulkan backend: * supports_blend_operation_advanced_coherent * Added the following feature to the renderer: * mBlendOperationAdvancedFeatures * It will be used to query advancedBlendCoherentOperations from the physical device. Bug: angleproject:42262258 Change-Id: I2949002d053700e89d92358d6e7c80c714ea36ee Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5634380 Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi 6ac37446 2024-06-17T15:38:09 Vulkan: Add feature for VK_KHR_maintenance5 This extension expands the pipeline flag bits, one of which is needed for VK_EXT_legacy_dithering v2 for dynamic rendering. Bug: angleproject:42267038 Change-Id: I45f2c47fbd016f60c3e52fda80d148d9f147bd71 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637154 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 65f8dc8e 2024-06-12T17:01:54 Vulkan: Remove traces of VK_MSRTSS_GOOGLEX Devices that shipped this unreleased extension should have long been updated to VK_MSRTSS_EXT Bug: angleproject:4836 Change-Id: I23736ebf28afd4a6f3b5b0d5a6417b3e7564c293 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5627575 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi c519a4a6 2024-06-10T15:56:36 Vulkan: Add dynamic rendering features Bug: angleproject:42267038 Change-Id: Ic2cdc277f6bb1bb3ce273a866bdb2ce6f5930355 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5617653 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 295ff607 2024-06-05T14:49:33 Vulkan: Precompute stageMask of kImageMemoryBarrierData Right now every time we need a pipelineStage in kImageMemoryBarrierData, we are doing a bitwise AND with mSupportedVulkanPipelineStageMask. This get called multiple times from barrier call. This CL adds mImageLayoutAndMemoryBarrierDataMap that has already precomputed all stageMask, thus avoid run time bitwise OR. This CL also precomputes the bufferWritePipelineStageMask so that flushImpl can be use it without construct every time. Bug: b/345279810 Change-Id: I878bd31c967cd217477061976f07df13b043fa7f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601073 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 87bbeaee 2024-06-03T15:04:25 Vulkan: Reduce VkEvent counts by using EventStage enums Right now we are using too many VkCmdSetEvents and causes some of the deqp tests timeout on CI bots (because of VVL is very slow along with the number of events being used). RefCountedEvents are per ImageLayout. But some of ImageLayous have the same VkPipelineStageFlags, for example TransferSrc and TransferDst. This CL changes RefCountedEvent to per unique VkPipelineStageFlags instead of per ImageLayout, thus allows TransferSrc and TransferDst to share one VkEvent. To do that, EventStage enum and kEventStageAndPipelineStageFlagsMap table are added to define the predefined VkPielineStageFlags that ANGLE uses. RefCountedEvent now keeps EventStage instead of ImageLayout. To further reduce the CPU overhead, a customized mPipelineStageMaskAndEventMap table is precomputed in renderer with supported vulkan pipeline stages. With this CL, previously timed out tests such as KHR-GLES3.copy_tex_image_conversions.forbidden.renderbuffer_cubemap* now passing. Bug: b/336844257 Change-Id: I021a8f1d6112d5cf96c61652c9af5f679b1172eb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597732 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Mohan Maiya 6aad8a89 2024-05-31T14:46:28 Vulkan: Remove combineAllShadersInPipelineLibrary If we have VK_NULL_HANDLE as the descriptor set layout handle for both pre-rasterization and fragment shader subset pipelines we run into VVL - VUID-VkGraphicsPipelineCreateInfo-pLibraries-06681 Need to work around this by having the renderer store a placeholder descriptor set layout handle for an empty DescriptorSetLayoutDesc that can be reused across all contexts Bug: angleproject:8677 Tests: EGLMultiContextTest.NonSharedContextsReuseDescritorSetLayoutHandle* Change-Id: I22e7f39c497d7f668afe7cb26690f6a9de49831b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5587990 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 1a9a703b 2024-05-21T11:14:40 Vulkan: Add DeviceQueueIndex to Context/BufferHelper/ImageHelper This CL adds a utility class DeviceQueueIndex, which encapsulates queueFamilyIndex and the queueIndex into one integer value so that we can pass around to barrier function. vk::Context and BufferHelper and ImageHelper class now keeps mCurrentDeviceQueueIndex instead of mCurrentQueueFamilyIndex. For All contexts by default it gets the default queue from renderer (which is always the one corresponding to Medium priority). For ContextVk, when priority changes it update mCurrentDeviceQueueIndex to match new context priority. Bug: b/337135577 Change-Id: I62cc483cfdb3e974d38db074e671c57299300074 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5555903 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao b22cce5f 2024-05-21T10:55:27 Vulkan: Remove Renderer::getDeviceQueueIndex Renderer::getDeviceQueueIndex() returns queueFamilyIndex. There is a function that already returns mCurrentQueueFamilyIndex, so this function is now removed. This CL also renames ImageHelper::isQueueChangeNeccesary to isQueueFamilyChangeNeccesary Bug: b/337135577 Change-Id: I3cd9ded1414d1389e162aaa5399c231a987f871e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5553067 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao f82d812d 2024-05-16T15:46:05 Vulkan: Fix EventBarrier bug when asyncSubmission is enabled Since we have moved RefCountedEvent garbage collection into ShareGroupVk, we have changed the reference counting to use non-atomic. There is a bug with async submission code path where the executeSetEvents gets called from submission thread which does not have share group lock. This CL fixes this bug by storing VkEvent in RenderPassCommandBufferHelper so that executeSetEvents uses VkEvent instead of RefCountedEvent when async submission is enabled. This CL also adds assertion that RefCountedEvent::releaseImpl does not get called from async submission thread. Bug: b/336844257 Change-Id: Ifcbd5a09d2bc7636cc15b2c6728dbbca103d4d9c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5544449 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 0636b509 2024-05-06T12:36:20 Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (2/3) One of the problem we had with RefCountedEvents is CPU overhead comes with it, and some part of the CPU overhead is due to atomic reference counting. The RefCountedEvents are only used by ImageHelper and ImageHelpers are per share group, so they are already protected by front end context share lock. The only reason we needs atomic here is due to garbage cleanup, which runs in separate thread and will decrement the refCount. The idea is to move that garbage list from RendererVk to ShareGroupVk so that access of RefCountedEvents are all protected already, thus we can remove the use of atomic. The down side with this approach is that a share group will hold onto its event garbage and not available for other context to reuse. But VkEvents are expected to be very light weighted objects, so that should be acceptable. This is the second CL in the series. In this CL, we added RefCountedEventsGarbageRecycler to the ShareGroupVk which is responsible to garbage collect and recycle RefCountedEvent. Since most of ImageHelper code have only access to Context argument, for convenience we also stored the RefCountedEventsGarbageRecycler pointer in the vk::Context for easy access. vk::Context argument is also passed to RefCounteEvent::init and release function so that it has access to the recycler. The garbage collection happens when RefCountedEvent is needed. The per renderer recycler is still kept to hold the RefCounteEvents that gets released from ShareGroupVk or when it is released without access to context information. Bug: b/336844257 Change-Id: I36fe5d1c8dacdbe35bb2d380f94a32b9b72bbaa5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5529951 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 5332ab8c 2024-05-10T19:48:34 Vulkan: Add RefCountedEventRecycler to vk::Renderer This CL adds event recycler in vk::Renderer to avoid the constant create and destroy of VkEvents. When RefCountedEvent is destroyed previously, it now goes into per renderer recycler. When RefCountedEvent is created previously, it now dips into this recycler and fetch it. Before we issue VkCmdSetEvent, if this event was from recycler, we also issue VkCmdResetEvent before VkCmdSetEvebt. When glFinish/EGLSwapBuffer is called or context gets destroyed, this recycler is purged to keep the free count under limit. Bug: b/336844257 Change-Id: I92ec1b183f708112a96c3d06fcfa265024f5aa04 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5519174 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 3d04180c 2024-05-02T17:30:02 Vulkan: Add a dedicated garbage list for RefCountedEvents Previously each individual RefCountedEvent is wrapped into a GarbageObject. That is the reason behind RefCountedEvent being a subclass from WrappedObject, since vk::GetGarbage call requires garbage object is a subclass of WrappedObject. This CL adds a new garbage list dedicated for RefCountedEvents, named mRefCountedEventGarbageList. With this new change, we no longer limited by the vk::GetGarbage requirements since it no longer called for RefCountedEvents. RefCountedEventCollector is a vector of RefCountedEvents and every time a RefCountedEvent needs to be released, it adds into the collector. Then the event collector entire thing is treated like a garbage object and gets ResourceUse tracked and added into mRefCountedEventGarbageList. This list gets walked and cleaned when GPU is completed. This CL is also a preparation for later CLs that adds event recycle support. Bug: b/336844257 Change-Id: I4eff69b66922dfe5521b6994f240e967ff3726bd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5516458 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi c3a1cae4 2024-04-15T14:58:55 Use angle::SimpleMutex everywhere in libGLESv2 Only cases left that use std::mutex are: - Share group and the context ErrorSet mutexes as they need try_lock() - Anywhere mutexes are used in conjunction with std::condition_variables (as they explicitly require std::mutex) Bug: angleproject:8667 Change-Id: Ib6d68938b0886f9e7c43e023162557990ecfb300 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5453294 Reviewed-by: Roman Lavrov <romanl@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao a96e9197 2024-04-25T10:35:02 Vulkan: Add RefCountedEvent class and VkCmdSetEvent call This CL defines RefCountedEvent class that adds reference counting to VkEvent. CommandBufferHelper and ImageHelper each holds one reference count to the event. Every time an event is added to the command buffer, the corresponding RefCountedEvent will be added to the garbage list which tracks the GPU completion using ResourceUse. That event garbage's reference count will not decremented until GPU is finished, thus ensures we never destroy a VkEvent until GPU is completed. For images used by RenderPassCommands, As RenderPassCommandBufferHelper::imageRead and imageWrite get called, an event with that layout gets created and added to the image. That event is saved in RenderPassCommandBufferHelper::mRefCountedEvents and that VkCmdSetEvents calls are issued from RenderPassCommandBufferHelper::flushToPrimary(). For renderPass attachments, the events are created and added to image when attachment image gets finalized. For images used in OutsideRenderPassCommands, The events are inserted as needed as we generates commands that uses image. We do not wait until commands gets flushed to issue VkCmdSetEvent calls. A convenient function trackImageWithEvent() is added to create and setEvent and add event to image all in one call. You can add this call after the image operation whenever we think it benefits, which gives us better control. (Note: Even if forgot to insert the trackImageWithEvent call, it is still okay since every time barrier is inserted, the event gets released. Next time when we inserts barrier again we will fallback to pipelineBarrier since there is no event associated with it. But that is next CL's content). This CL only adds the VkCmdSetEvent call when feature flag is enabled. The feature flag is still disabled and no VkCmdWaitEvent is used in this CL (will be added in later CL). Bug: b/336844257 Change-Id: Iae5c4d2553a80f0f74cd6065d72a9c592c79f075 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5490203 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 950afec4 2024-04-30T09:38:43 Vulkan: Add VK_KHR_synchronization2 feature flag This CL adds VK_KHR_synchronization2 feature flag and enables the feature if exists. Bug: b/336844257 Change-Id: I201768e32c997125472c6a005c4635141441451e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5499379 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Gowtham Tammana acb8b33f 2024-04-16T14:08:34 Vulkan: Enable 8/16 bit storage buffer extensions The support for 8bit and 16bit storage buffers are exposed via VK_KHR_{8,16}bit_storage vulkan extensions. Add checks for these extensions and enable them if present. The changes in FeaturesVk_autogen.h in the change are generated by running the run_code_generation.py script. Bug: angleproject:8676 Signed-off-by: Gowtham Tammana <g.tammana@samsung.com> Change-Id: Idcda416e3eb6a735e021cd5bb0a182af341e9a16 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5491781 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi d55464ff 2024-04-04T14:13:02 Vulkan: Remove the supportsDepthClipEnable feature This feature is unused since: https://chromium-review.googlesource.com/c/angle/angle/+/4545084 Bug: angleproject:3970 Change-Id: I78acfda80d4ae04d1387a452e9f52a55a4298a4c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5426530 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi c71a67de 2024-03-27T15:50:00 Vulkan: Move pipeline cache graph dump to renderer In preparation for moving some caches to the share group. Bug: angleproject:6565 Bug: angleproject:8629 Change-Id: I1a06a18417502e499da0edb9abb0d510e3ad99ce Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5401513 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: mohan maiya <m.maiya@samsung.com>
Shahbaz Youssefi 9475ac40 2023-11-15T10:25:06 Vulkan: Make efficient MSAA resolve possible Prior to this change, using a resolve attachment to implement resolve through glBlitFramebuffer was done by temporarily modifying the source FramebufferVk's framebuffer description. This caused a good deal of complexity; enough to require the render pass to be immediately closed after this optimization. The downsides to this are: - Only one attachment can be efficiently resolved - There is no chance for the MSAA attachment to be invalidated In this change, resolve attachments that are added because of glBlitFramebuffer are stored in the command buffer, with the FramebufferVk completely oblivious to them. When the render pass is closed, either the FramebufferVk's original framebuffer object is used (if no resolve attachments are added) or a temporary one is created to include those resolve attachments. With the above method, the render pass is able to accumulate many resolve attachments as well as have its MSAA attachments be invalidated before it is flushed. For a FramebufferVk that is resolved in this way, there used to be two framebuffers created each time and thrown away as the code alternated between starting a render pass without a resolve attachment and then closing with one. With this change, there is now one framebuffer (without resolve attachments) that is cached in FramebufferVk (and is not recreated every time), and only the framebuffer with resolve attachments is recreated every time. Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there would be no framebuffers to create and destroy, and this change paves the way for that support too. WindowSurfaceVk framebuffers are still imagefull. Making them imageless adds unnecessary complication with no benefit. ----------------- To achieve efficient MSAA rendering on tiling hardware, applications should do the following: ``` glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO); // Clear the framebuffer to avoid a load // Or invalidate, if not needed to load: // glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...); glClear(...); // Draw calls // Resolve into the single sampled framebuffer glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO); glBlitFramebuffer(...); // Immediately discard the contents of the MSAA buffer, to avoid store glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...); ``` The above would translate to the following Vulkan render pass: - MSAA LOAD_OP_CLEAR/DONT_CARE - MSAA STORE_OP_DONT_CARE - Resolve LOAD_OP_DONT_CARE - Resolve STORE_OP_STORE This makes sure the MSAA data doesn't leave the tile memory and greatly reduces bandwidth usage. Once anglebug.com/4892 is fixed, this would also allow the MSAA image to never be allocated either. Bug: angleproject:7551 Bug: angleproject:8625 Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi efd41bd2 2024-03-15T13:25:03 Vulkan: Rename ResourceVk.* to vk_resource.* This file adds helpers to namespace vk, so its name is changed for consistency with other namespace vk files. Bug: angleproject:8564 Change-Id: I6525e7609eb9385f2a3eecaa7c52b7417fda7f12 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370108 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 914fe61b 2024-03-15T13:20:49 Vulkan: Rename RendererVk.* to vk_renderer.* Done in a separate CL from the move to namespace vk to avoid possible rebase-time confusion with the file name change. Bug: angleproject:8564 Change-Id: Ibab79029834b88514d4466a7a4c076b1352bc450 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370107 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>