Render: render.backend says why it renders on the CPU; mcp --gpu documented (#262)

get_project / render.backend reported "gpuAcceleration": true with
"active": "cpu" and no reason, which read as a broken GPU. The
headless MCP server only attaches the GPU compositor when started with
--gpu, which docs/agents.md didn't mention, and a failed --gpu said
only "no usable GPU adapter" (the adapter's error went to a log no
one sees). The session now keeps the host's reason there is no GPU
compositor (accel_note): the CLI's "headless: renders on the CPU
unless started with --gpu", or the desktop app's compositor setup or
retirement error. The status reports it as `why` whenever it renders
on the CPU (or that the project's renderer is Software Only). --gpu
failures include the adapter's error (Gpu::try_headless).
docs/agents.md documents `mcp --gpu`.

Test: render_backend_says_why_it_renders_on_the_cpu (engine).
Checked with effectcraft-cli mcp and mcp --gpu.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
bflatastic
2026-10-08 18:09:01 +07:00
co-authored by Claude Opus 5.5
parent 0d3b5ed286
commit 4eb69e7577
7 changed files with 46 additions and 5 deletions
+4 -1
View File
@@ -36,7 +36,10 @@ You can also register it from the command line:
Desktop, Cursor and the like) take the same `command` and `args`.
- **Headless** (`["mcp"]`): an in-process session with no window. Add `"--demo"` or
`"--project", "file.ecproj"` to start with content. Startup is instant.
`"--project", "file.ecproj"` to start with content. Startup is instant. It renders on the CPU
unless you add `"--gpu"` (`["mcp", "--gpu"]`), which attaches the GPU compositor on a device of
its own; if no adapter is usable the server says why and exits. `get_project`'s `renderer`
(`render.backend`) reports `active` (`gpu` / `cpu`) and, on the CPU, `why`.
- **Bridge** (`["mcp", "--bridge", "9877"]`): drives a running `effectcraft --control 9877`, so you
see every change live. Bridge mode adds `screenshot` and the `ui_*` tools.