Files
workinf_Blender_Wasm/docs/status/M11-05.md
mes123456 0fe8d2bb56
Some checks failed
M6 deployable RC / quick (push) Has been cancelled
M6 deployable RC / chromium (push) Has been cancelled
M6 deployable RC / release (push) Has been cancelled
Advance M8-M11 parity workflows
2026-08-17 04:37:07 -04:00

48 lines
2.5 KiB
Markdown

# M11-05 Status
status: done
task: Server-only routing for Cycles, complex Eevee and hardware render backends
updated: 2026-08-17 America/New_York
## Scope
Schema 1 `RenderRoutingRequestIR` separates execution target from endpoint
availability. Only bounded Eevee on WebGL2, or WebGPU after both browser and bundled
renderer capability checks, may return `WEB_LOCAL_BOUNDED/READY`. Cycles, complex
Eevee, Workbench final rendering and CUDA/OptiX/HIP/Metal/oneAPI requests always
target `SERVER_JOB`; the default unconfigured endpoint returns
`SERVER_JOB_UNAVAILABLE` without a local approximation. Unknown, syntactically valid
SceneIR engine identities fail closed as `PLATFORM_CAPABILITY_UNAVAILABLE`.
Setting `serverRenderAvailable:true` can make a server route `READY`, but only proves
the routing decision. It does not submit a job or claim the source/build/settings/
output hash contract reserved for M11-06.
## Evidence
- `WEB_TEST_PORT=5556 npm --prefix web run test:render-routing`: unit 3/3 and
Chromium 1/1. The browser reads `BLENDER_EEVEE` from the real M11 reference `.blend`
through the production WebEngine Worker before checking the local/server matrix.
- Cycles, complex Eevee and OptiX all remained `SERVER_JOB/BLOCKED` with
`SERVER_JOB_UNAVAILABLE` under the production default. A synthetic configured
server context returned `SERVER_JOB/READY`, never a Web target.
- Unbundled WebGPU remained `WEB_LOCAL_BOUNDED/BLOCKED` with
`WEBGPU_RENDERER_UNAVAILABLE`; an unknown engine remained server-targeted and
blocked with `PLATFORM_CAPABILITY_UNAVAILABLE`.
- Typecheck, lint, production build (75 modules) and `git diff --check` passed.
## Implementation Hashes
- `web/protocol/render-routing.ts`: `2d41d48609635c810572aaae95979df2fe9e49bbd130c60d70f64042c5d0f097`
- `web/app/src/three-adapter/render-routing.ts`: `f360c05fa62aa830a486c5be4747488fcbb5ba9b68d82b4f7187e1267da46fa6`
- `web/tests/unit/render-routing.test.mjs`: `4ac2e7a6c2265f948d971f72effb4ff9ad1c51839ab6c06d496fc2b0768c4fa8`
- `web/tests/e2e/render-routing.spec.ts`: `e5572d9ad9426f1dcc1856fe426261910093fa2f5460117e4ffdcfc7b23b10a1`
- `tests/golden/M11-05/render-routing.json`: `53c5d3a2e51f251d14953594567081597be4250be5b1236832370e74805bd35d`
- `web/package.json`: `716a5331990618892bca97f48c7eef589a5af6c5131b8cf3ae52a1b9d923644c`
## Rollback
Remove the M11-05 routing protocol/wrapper, unit/E2E/golden/package command, restore
M11 to 4/14 and remove the N-019 server-routing completed slice. Keep M11-04 realtime
reference metrics and all earlier lighting/resource behavior unchanged.