Major TBDR performance penalty on macOS due to excessive dynamic rendering passes with the Vulkan rendering backend

Short description of the issue
The experimental Vulkan backend in 26.2 fragments its rendering pipeline by issuing 45+ dynamic render passes (vkCmdBeginRendering) and blits per frame inside a single command buffer. While command submission batching is functioning correctly (only 1-2 vkQueueSubmit calls per frame), the sheer volume of distinct render passes causes a severe performance penalty on Tile-Based Deferred Rendering (TBDR) architectures like Apple Silicon. Because MoltenVK translates each vkCmdBeginRendering into a separate MTLRenderCommandEncoder, the GPU is forced to repeatedly flush its ultra-fast, on-chip tile memory out to system RAM, completely bottlenecking memory bandwidth.

Steps to reproduce the issue

1. Launch Minecraft Java Edition version 26.2.

2. Enable the Vulkan rendering backend in the graphics options.

3. Load into a world and capture a Metal System Trace using Xcode Instruments.

4. Expand a single vkQueueSubmit MTLCommandBuffer in the trace hierarchy.

5. Observe the 45+ independent vkCmdBeginRendering RenderEncoder and BlitEncoder instances executing sequentially within that single command buffer.

Expected result
Vulkan draw commands are consolidated into a minimal number of unified dynamic rendering passes. Intermediate data (like depth or G-buffers) remains in on-chip tile memory rather than being flushed to main memory between dozens of micro-passes.

Actual result
The pipeline issues 45+ isolated vkCmdBeginRendering calls per frame. On Apple Silicon and other mobile architectures, this forces constant, expensive hardware memory flushes that saturate bandwidth and cripple framerates.