Document Forward+ measurements and Linux lighting evidence

docs/manual/editor/profiling.md

@@ -130,6 +130,15 @@ submitted-light count of zero is a different workload from 128 lights whose
 shadows are disabled. See [Lighting](lighting.md) for the capacity policy and
 [Diagnostics](diagnostics.md) for the Editor counters.
 
+The same sample includes `effective_lighting_path` (`forward` or `tiled`),
+`gpu_light_tiles_ms`, and `light_tile_count`. Stored candidate and overflow
+counts are present only when visibility diagnostics readback was enabled;
+`light_tile_counts_valid: false` means their `null` values are unavailable,
+not zero. The normal `Auto` setting currently resolves to `forward` after the
+fixed dense 1080p benchmark showed that tile construction cost outweighed its
+raster savings. A C++ renderer integration can explicitly request `Tiled` for
+a localized-light scene, then check the actual path before comparing timings.
+
 The fixed-scene benchmark compares 0, 4, 16, 32, 64, and 128 local lights under
 Direct, GPU frustum, and GPU occlusion visibility, with shadows on and off. Its
 wrapper runs three independent 1920×1080 repetitions per configuration, each
@@ -162,6 +171,18 @@ frame** at 32, 64, or 128 lights on the Linux physical reference GPU. The
 states the measured decision and scope. A software Vulkan run checks
 functionality, not physical GPU performance.
 
+For a direct comparison of the two algorithms on the same scene, invoke the
+Release executable twice with `--lighting forward` and `--lighting tiled`,
+using the same `--lights`, `--shadows`, `--visibility`, and output size. The
+default `--light-layout dense` preserves the fixed benchmark scene;
+`--light-layout localized` reduces point-light ranges to 1.75 units as a
+separately labelled workload. Compare `gpu_build_plus_raster_ms`, which includes
+`gpu_light_tiles_ms`, rather than raster time alone. One optional diagnostic
+frame with `--tile-diagnostics on` reports candidate and overflow counts but
+adds a GPU readback, so do not mix it into the timed runs. The
+[Forward+ measurement](https://github.com/emil28092005/Faset_Engine/blob/main/docs/studies/23-p3-forward-plus-2026-09-24.md) retains
+raw frames, shader hashes, and the decision.
+
 ## Current performance scope
 
 The accepted MVP path uses direct draws and CPU culling; P2 adds optional GPU