Implement RenderGraph Memory aliasing

[JeanPhilippeKernel]

What this is (and isn't)

RGTransientPool::TryAlias (ZEngine/ZEngine/Rendering/Renderers/RenderGraph.h/.cpp) already does exact-match slot reuse: a freed transient resource's handle/VkImage gets handed to a new resource only when format, dimensions, and layer count match exactly, and their lifetimes don't overlap. That is not memory aliasing.

Real aliasing means multiple transient resources with different sizes/formats sharing the same underlying VkDeviceMemory region — binding several VkImages to overlapping offsets within one shared block (vkBindImageMemory against a block sized for the largest resource, or a VmaVirtualBlock-style sub-allocator), with explicit VkMemoryBarriers enforcing that a later-lifetime resource's first write happens-after the earlier-lifetime resource's last read/write. Get a barrier wrong and the failure mode is silent GPU corruption, not a crash — this needs to be built carefully, not bolted on.

What's already in place

The scaffolding this needs already landed as part of the RenderGraph topological-sort work (PR #748): RGResource::FirstPassIndex/LastPassIndex are computed off real sorted execution order (not raw declaration order), so lifetime non-overlap can be determined correctly. That's necessary but not sufficient — it tells you when two resources could alias, not how to actually bind them to shared memory or insert the hazard barriers between them.

What's still needed

• A GpuAllocator pool variant that supports sub-allocating/overlapping regions for aliasing candidates, rather than the current domain-segregated fixed/auto-sized pools (ZEngine/ZEngine/Core/Memory/GpuAllocator.h/.cpp).
• Hazard-barrier insertion at alias boundaries, threaded through RenderGraph's existing barrier-emission path.
• A real test strategy for a class of bug (aliasing hazards) that's easy to get wrong in a way normal rendering output won't reveal.

Recommendation

Don't start on spec — this is real complexity for a payoff (memory savings on transient render targets) that only matters under actual GPU memory pressure. Worth revisiting once a real scene/profile demonstrates that pressure; until then this stays a documented, deliberate gap rather than a silent one.

[JeanPhilippeKernel]

Status update — real topological sort shipped, memory aliasing still deferred

As part of this month's rendering-foundation hardening pass, RenderGraph::BuildTopology now does a real Kahn's-algorithm sort over RAW/WAW/WAR hazard edges derived from each pass's declared reads/writes (previously it was a flat insertion-order loop). BuildLifetimes now indexes by real sorted execution order, not raw declaration order.

This is deliberately not the same thing as this issue — no actual VkDeviceMemory sub-allocation/aliasing across differently-sized/typed resources is implemented. What exists today (RGTransientPool::TryAlias) is exact-match handle/texture reuse only (same format/size, non-overlapping lifetime).

Full memory aliasing is deferred, not started, for two reasons:

1. It needs VkMemoryBarrier-based hazard tracking for aliased-but-not-yet-overlapping resources, plus custom VMA pool tuning (VMA_POOL_CREATE_ALGORITHM, alignment/granularity queries via vkGetImageMemoryRequirements) — i.e. it's coupled to the GPU allocator's segregated-pools work, not independent of it.
2. It needs BuildLifetimes's FirstPassIndex/LastPassIndex computed against real execution order to be correct scaffolding — which only just landed this month. Building aliasing on top of the old (declaration-order-indexed) lifetimes would have been building on a foundation that was quietly wrong the moment the sort started reordering anything.

The scaffolding (BuildLifetimes, now correctly sorted-order-indexed) is ready for a future aliasing pass to build on. Leaving this issue open, unstarted, for that future work.