bb3369b709
The software and HDR export paths already composite on the shared device (the eframe device, via render_next_video_frame), so they can consume the same hardware-decoded NV12 GPU frames the preview uses — no CPU download/upload: - ExportGpuResources gains the Nv12BlitPipeline; the export compositor's Video arm branches on inst.gpu (NV12 blit, mirroring stage.rs) vs the RGBA upload path. - render_frame_to_gpu_rgba takes a hardware_ok flag: true for the software video + image export (shared device), false for the zero-copy path (own device, must download). render_frame_to_yuv10_hdr sets it true. Drops the 4K software/HDR-export decode wall (HW decode + GPU composite, no per-frame RGBA upload). The common Linux H.264 zero-copy path is unchanged (separate device) — that's pt 2. Falls back to software when no shared device / importer (flag is harmless then: get_frame returns CPU anyway). Compiles. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| beamdsp | ||
| egui_node_graph2 | ||
| gpu-video-encoder | ||
| lightningbeam-core | ||
| lightningbeam-editor | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| GPU_VIDEO_DECODE_PLAN.md | ||
| build-static.sh | ||
| build-windows.bat | ||