Hartmut/HartOMat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: multi-GPU queue routing for legacy still renders (M2)

Browse Source 
dispatch_order_line_render now routes still renders (non-animation,
non-cinematic) to a secondary GPU queue when MULTI_GPU_LIGHT_RENDER_QUEUE
is configured and that queue has active Celery workers.

- config.py: multi_gpu_light_render_queue setting (default "" = disabled)
- render_order_line.py: implement the routing stub — load output_type via
  selectinload, check render_settings.animation + .cinematic flags, call
  _inspect_active_worker_queues (reused from workflow_graph_runtime) with
  0.5s timeout to check if the light queue is live

No behaviour change when MULTI_GPU_LIGHT_RENDER_QUEUE is not set.
Enable by setting it to "asset_pipeline_light" and adding a
render-worker-light service with concurrency=1 to docker-compose.

docs: learnings erfasst — multi-GPU queue routing M2

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Hartmut
2026-07-22 15:12:07 +02:00
co-authored by Claude Sonnet 4.6
parent 3401b06b19
commit 23605783bd
3 changed files with 34 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
LEARNINGS.md
+3
View File
@@ -7,6 +7,9 @@
## Learnings
### 2026-07-22 | Architecture | Multi-GPU Queue Routing für Legacy-Dispatch implementiert
M2: `dispatch_order_line_render` leitet Still-Renders an eine zweite GPU-Queue um wenn `MULTI_GPU_LIGHT_RENDER_QUEUE` gesetzt ist UND diese Queue aktive Worker hat (Celery inspect). Animationen und Cinematics bleiben immer auf `asset_pipeline`. Neue Settings-Option `multi_gpu_light_render_queue: str = ""` in config.py — Default leer = disabled. `_inspect_active_worker_queues()` aus `workflow_graph_runtime.py` wiederverwendet (timeout=0.5s). Kein Breaking-Change: ohne die Env-Variable verhält sich die Dispatch-Funktion exakt wie vorher.
### 2026-07-22 | Architecture | BLENDER_CINEMATIC Workflow-Graph-Node implementiert
Der cinematic Render-Pfad hatte keinen eigenen Workflow-Graph-Node — Migration 071 hatte alle cinematic Output-Types auf `legacy_only` gezwungen als Sicherheitsnetz. M1 fügt jetzt `StepName.BLENDER_CINEMATIC` hinzu, zusammen mit: (1) Node-Definition im `workflow_node_registry.py` mit denselben Szene/Camera/Material-Feldern wie BLENDER_STILL, aber ohne Animations-Params (frame_count/fps sind im cinematic_render.py-Script hartkodiert auf 250 @ 25fps), (2) `render_cinematic_task` in `tasks.py` — folgt dem Pattern von `render_order_line_still_task`, gibt mp4 aus, nutzt `_finalize_graph_turntable_output`/`_finalize_shadow_turntable_output` da cinematic = mp4, published mit `asset_type="turntable"`, (3) STEP_TASK_MAP + `_ORDER_LINE_RENDER_STEPS` + `_build_task_kwargs` + `_predict_render_output_artifact` + `_artifact_kind_override_for_step` in `workflow_graph_runtime.py` alle aktualisiert. Kein neues DB-Migration nötig: Admins können cinematic Output-Types jetzt manuell von `legacy_only` auf `graph` umstellen und ein Workflow-Definition mit BLENDER_CINEMATIC-Node zuweisen.