JeanPhilippeKernel/RendererEngine

Problem Several engine warnings can repeat every frame or allocation attempt, obscuring actionable validation and runtime errors. The Linux validation logs show repeated [GPU] Pool for domain … exhausted — falling back to default pool messages as a concrete example. Scope Add a reusable, thread-safe rate-limiting/deduplication mechanism for high-frequency warnings. Apply it first to the GPU pool-exhaustion fallback warning. Preserve the first occurrence and periodically emit a concise suppressed-count summary. Do not rate-limit errors or validation-layer messages. Acceptance criteria A sustained repeated warning does not produce one line per frame/allocation. The log still makes the initial condition and the number of suppressed repeats visible. Normal one-off warnings retain their current behavior.

Type Bug Feature Refactor / cleanup Task / chore Overview Define and document the engine-wide policy for scalar math, vector/matrix types, and optional SIMD acceleration across macOS, Windows, and Linux. The immediate baseline is correct standard-library scalar transcendental math; this task decides when and how optimized paths are introduced without exposing platform libraries to engine consumers. Context Zodiac Engine owns its Vec, Mat, and quaternion types. The former custom trigonometric approximation was not accurate enough near ±π/2 and full rotations, so PR #795 replaces it with std::sin and std::cos. There is no need to adopt a broad third-party math dependency merely to provide correct scalar math. The closed #33 tracked the historical GLM abstraction direction but has no retained requirements. This issue is a fresh, cross-platform policy and measurement task. What needs to be done Establish std::<cmath> as the correctness baseline for scalar transcendental operations

Summary Intel HD/UHD Graphics on Windows uses a proprietary Vulkan driver (VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS) with fundamentally broken synchronization: fences and timeline semaphores signal before GPU execution completes. This causes premature resource reuse and VK_ERROR_DEVICE_LOST with no reliable Vulkan workaround. The engine currently halts at startup with a clear message when this driver is detected (see VulkanDevice.cpp — device selection). Impact Users with Intel HD/UHD Graphics on Windows (HD 620, UHD 620, UHD 630, etc.) cannot run the engine. Root causes confirmed VkFence signals before associated command buffer execution completes (early-signalling bug) Timeline semaphores exhibit the same early-signalling behaviour vkQueueSubmit2 with any timeline semaphore signal hangs or corrupts device state vkQueueWaitIdle is the only reliable CPU-GPU synchronization primitive, making a performant render loop impossible Drivers NOT affected Intel Arc on Windows (newer driver s

We should probably add in support for ninja in the CMake Presets as an added option. Ninja has the benefit of building in parallel by default.