The log named every GPU we rejected but never the one we chose, which…

[nnewson]

… stops being a curiosity the moment a machine has two drivers installed

Device selection logged a named reason for each unsuitable GPU and then said nothing about the one it picked. That was survivable while a Mac had exactly one usable ICD. It is not now: MoltenVK and KosmicKrisp both install into /usr/local/share/vulkan/icd.d, both advertise Vulkan 1.4, and both are suitable — so which one served a run was only discoverable by re-running under VK_DRIVER_FILES.

That matters because the driver changes how everything else in the log should be read. A rendering difference, a VUID, or a performance figure means something different depending on which driver produced it, and the log had no record of which one that was.

pickPhysicalDevice now logs the accepted device's name, driver name and driverInfo from VkPhysicalDeviceDriverProperties, and its API version through the existing versionString helper:

GPU 'Apple M2 Pro' via KosmicKrisp (vulkan-sdk-1.4.357.0
(git-6e2f85ffe3)) — Vulkan 1.4.357
GPU 'Apple M2 Pro' via MoltenVK (1.4.1) — Vulkan 1.4.334

At info, so it stays behind FE_LOG=render:info like the rest of the render category's detail rather than adding a line to every run.

Verified on the way to this: the engine runs on KosmicKrisp with no engine changes at all — 13 scenes clean under --require-validation with zero VUIDs, including the GPU VDPM front (0 fallback, 0 non-clean, 0 ancestor-fail), cloth, particles, shadows and ragdoll; output differs from MoltenVK by a mean of 0.09/255 and a max of 5/255, which is shader-compiler rounding rather than a rendering difference. The portability path behaved as designed — KosmicKrisp is conformant, does not advertise VK_KHR_portability_subset, and the planner simply did not enable it. Selection order is unchanged: with both installed, MoltenVK still wins, so KosmicKrisp remains opt-in via VK_DRIVER_FILES.