Cycles GPU out-of-memory allocation failure: measuring texture vs. geometry VRAM pressure before optimization

Error context

Cycles GPU rendering aborts with a CUDA, OptiX, HIP, Metal, or oneAPI allocation failure when scene data exceeds available VRAM. The failure originates in the Cycles device memory allocation path, not Blender's core.

Goal and uncertainty

The objective is to determine whether a specific scene's memory pressure is dominated by texture memory or by geometry/BVH data before applying any optimization. Texture downscaling, tiled/UDIM workflows, instancing, and decimation address different consumers, and the correct choice depends on measured VRAM usage rather than assumption.

Blender exposes memory statistics via the status bar scene statistics and Cycles render statistics/log output, but exact reporting varies by version and backend. Automatic fallback to CPU on allocation failure is also version- and backend-sensitive; some configurations simply fail the render.

Questions

1. Which combination of status-bar statistics, render-log output, and external VRAM monitoring reliably identifies the dominant memory consumer for a given backend and Blender version?
2. What is the documented procedure to capture peak per-category VRAM usage (textures, geometry, BVH, shader data) during a failed render attempt?