site: 2026-10-30 wiki refresh - new Project Goals, Performance and Interfaces and Stability pages; GSP explainer expanded (bare-metal behaviour + the two emulation modes); graphics pages (Graphics Execution, OpenGL, Vulkan, DirectX) with two new diagrams; status refresh across 15 pages; canonical docs updated (README status table, purpose-and-scope, performance contract); published to open-iov.org (67 pages, 0 problems)

1 files changed, 23 insertions, 13 deletions

diff --git a/wiki/FAQ.md b/wiki/FAQ.md
index 9472740..35554e5 100644
--- a/wiki/FAQ.md
+++ b/wiki/FAQ.md
@@ -5,7 +5,7 @@
 > [`../docs/09-reference/glossary-and-faq.md`](../docs/09-reference/glossary-and-faq.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-10-12, tree `master @ 2f066727`.
+Status: 2026-10-30, tree `master @ b4930168`.
 
 ## Project and positioning
 
@@ -27,26 +27,36 @@ not for the QEMU/emulated path
 ([`Install-and-First-Run.md`](Install-and-First-Run.md) §2).
 
 **Why is `nvidia-smi` working but my CUDA kernel not running?**
-Because execution is the frontier, not the setup. Today, a stock guest driver
-probes, `nvidia-smi` works, device enumeration works, and the full CUDA
-**driver-API** path (context creation, allocation, copies, free, destroy)
-completes; a guest **kernel launch** is forwarded to the physical engine queue
-but the engine does not yet execute the forwarded launch descriptor
-(`[wall]`). This is the project's known status, not a misconfiguration — see
+It probably is running: guest CUDA kernels execute on the physical GPU and
+verify — the vector-add, matrix-multiply and transformer clients are green on
+fresh boots. If a specific workload fails, the known classes are: multi-megabyte
+staged transfers between guest and device memory (under repair, failure modes
+proven), and simultaneous CUDA guests (per-guest execution isolation is in
+progress). This is the project's known status, not a misconfiguration — see
 [`Project-Status.md`](Project-Status.md) and
 [`Execution-Frontier.md`](Execution-Frontier.md).
 
+**Can I run OpenGL or Vulkan applications in the guest?**
+Partially, and it is an active frontier. The X server and GLX come up on the
+emulated vGPU with the stock driver, the engine executes real GL method
+streams (verbatim 3D replay plus synthesized launches), and the guest Vulkan
+pipeline runs end to end (device → command buffer → fence → readback).
+Rendered (non-black) frames are the remaining wall — see
+[`OpenGL.md`](OpenGL.md), [`Vulkan.md`](Vulkan.md) and
+[`Graphics-Execution.md`](Graphics-Execution.md).
+
 **How fast is it?**
-No published numbers yet. Copy-engine-class forwarding and its completion and
-fault relay are implemented (default off) and GR execution is the open
-frontier; even the initialization path has not yet been measured under the
-project's methodology. Any performance claim will ship together with its
-methodology and measurements.
+No published numbers yet. Kernel launches execute on the physical engine;
+what remains unmeasured is the project's own methodology — nothing ships as a
+performance claim without its measurements. The first scheduled measurement
+is the graphics target (60 fps sustained in one VM, no forcing).
 
 ## Compatibility
 
 **Will it support Windows guests?**
-Yes, it is a target: same architecture, measured bring-up.
+Yes, it is a target: same architecture, measured bring-up. No Windows guest
+has been booted on the emulated vGPU yet; the Windows/DirectX path (WDDM,
+`nvlddmkm`, Direct3D) is described on [`DirectX.md`](DirectX.md).
 [`Hardware-Software-Matrix.md`](Hardware-Software-Matrix.md) lists the
 support ladder.