Mike-Solar
48e99e56b7
docs/zh/plans/render-pipeline-threads.md M2: the graph's textures stay on the GPU from evaluation through presentation, and presentation runs on the UI's own wgpu device. - wgpu 25 -> 29 (naga 29) across the engine, unifying it with gpui_wgpu so engine textures are directly sampleable by the presenter (a single wgpu remains in the lockfile). - GpuContext::adopt/install_shared: the app registers the window's device at startup and the render thread renders on it; texture_handle hands the raw Arc<wgpu::Texture> to SurfaceSource::Texture - zero-copy present on Linux/FreeBSD. The shared slot replaces an engine context that has not touched the GPU yet (startup-order guard) and refuses once it has. - Texture::Gpu shares a GpuLease so clones release the registry token exactly once; the compositor, transitions and adjustment sweeps keep GPU textures end to end (no per-clip readbacks; GPU clears for black/generated frames). - Color management stays on the GPU: the output node + display ICC chain is baked into a 65^3 3D LUT with the exact CPU reference and applied by the present WGSL pass (manual trilinear); ColorTransformJob bakes its OCIO processor the same way. Neither path skips color management. - The explicit readback boundaries accept GPU textures: export encoder, CLI, worker shm, disk cache; CPU OpenFX already read back. - M5 dependency: the YUV->RGB GPU pass (BT.601/709/2020 x limited/full) matches colormath::yuv444p16_to_rgb_f32. - Acceptance: gpu_transfer_counters; single-clip and layered (multi-track + transition + adjustment) playback tests assert zero GPU->CPU readbacks, and the app test asserts adopted-device present is zero-copy. GPU tests hard-fail when OAK_REQUIRE_GPU is set (CI lavapipe) instead of skipping silently.
oak-cli (Rust)
Headless command-line consumer of the oak editor module crates — the Rust
rewrite of cli/main.cpp (which stays in the tree until cutover). Same
subcommands, same output format, same exit codes:
| exit | meaning |
|---|---|
| 0 | success |
| 1 | general error (bad project/media file, no sequence, I/O failure) |
| 2 | rendering unavailable or failed (e.g. no render backend) |
| 64 | usage error |
Build and test
cargo build --release # binary: target/release/oak-cli
cargo test # unit + integration tests
The crate is self-contained (M14 R2): it links the oak* module rlibs
directly (oaknode, oaktimeline, oakcodec, oakrender, oaktask,
oak_core) — no liboakengine dylib, no C ABI, no build.rs link step.
cargo test -p oak-cli stands alone.
Subcommands
Every subcommand of the C++ original is implemented:
oak-cli info <project.ove> <start> <end> <out_dir> project name/sequences/footage
oak-cli render <project.ove> <start_seconds> <end_seconds> <out_dir>
oak-cli probe <mediafile>
oak-cli transcode <input_media> <out> [width] [--format ppm|mp4]
Argument validation is faithful to the C++ (invalid start seconds,
invalid width, unknown --format … all exit 64). The output formatters
(src/fmt.rs) reproduce the C++ printf output byte for byte and are
golden-tested against the output captured from the C++ binary on the test
fixtures (tests/project_with_footage.ove, tests/demo.mp4); the PPM and
WAV writers (src/ppm.rs, src/wav.rs) are the exact ports of the C++
write_ppm/write_wav and are unit-tested.
Layout
src/
main.rs clap surface, --help/-h + unknown-command handling, dispatch
engine.rs module-native assembly layer (M14 R2): project load/create,
footage probe, sequence + clip assembly, montage resolution,
ticket rendering, synchronous export
fmt.rs golden output formatters (info/probe)
ppm.rs P6 PPM writer (f32/u8 frames)
wav.rs PCM s16 WAV writer (interleaved float samples)
cmd/ per-subcommand validation + module-crate calls
tests/cli.rs binary-level tests (exit codes, messages, usage errors)