gx
ad543054fc
Architectural review (2026-05-15) указал что cudaStreamSynchronize-only на producer-side не достаточен для cross-process visibility — NVIDIA Programming Guide §3.2.8 требует cudaIpcEventHandle_t. Phase 0 PoC v1 не проверял этот случай из-за cudaMemcpy который имеет implicit barriers. spike-v2 воспроизводит правильный сценарий: consumer запускает verify_kernel на ОТДЕЛЬНОМ stream'е (real-world use case — PyTorch / OpenCV CUDA), pattern включает row-based component для отлова partial-frame torn. Запуск 4 scenarios × 1500/600 frames: A-fhd60 (stream sync, FHD@60): 0 torn, p99=267µs, max=14.7ms B-fhd60 (event sync, FHD@60): 0 torn, p99=344µs, max=5.2ms A-4k30 (stream sync, 4K@30): 0 torn, p99=606µs, max=4.4ms B-4k30 (event sync, 4K@30): 0 torn, p99=437µs, max=3.7ms Все 4 показали 0 torn frames. R1 на single-host single-GPU фактически не воспроизводится — но NVIDIA contractually не гарантирует это. Decision: events as default (R1/R2 resolved). Architecture.md §6.6 закрыт. Tradeoff: mean latency +20µs, max latency в 3× ниже (predictable tail) + future-proof для multi-GPU. Также Dockerfile.dev — апдейт CUDA до 13.0.3 (12.4 не существует с devel-ubuntu24.04). Связано с PR review: R1, R2, R3 (R3, R4 — в следующих коммитах).
Docker for cuframes
Все сборки и тесты делаются в Docker. Хостовый CUDA toolkit не нужен — только NVIDIA driver + nvidia-container-toolkit.
Развёртывание dev-окружения
# Один раз (поднимет dev-контейнер на фоне)
docker compose -f docker/docker-compose.dev.yml up -d
# Войти в контейнер
docker compose -f docker/docker-compose.dev.yml exec dev bash
После up -d контейнер cuframes-dev живёт пока его не остановят. Repo
смонтирован в /workspace.
Проверка что CUDA видна:
docker compose -f docker/docker-compose.dev.yml exec dev nvidia-smi
docker compose -f docker/docker-compose.dev.yml exec dev nvcc --version
Что внутри
| Компонент | Версия | Зачем |
|---|---|---|
| Ubuntu | 24.04 | base |
| CUDA Toolkit | 12.4.1 | для nvcc, headers, runtime libs |
| cuDNN | 9 | для возможных bindings к ONNX |
| GCC | 12 | стандартный для Ubuntu 24.04 |
| Clang + clang-format + clang-tidy | системные | code style + static analysis |
| CMake | системный (≥3.28) | build |
| Ninja | системный | быстрее make |
| FFmpeg dev headers | системные (6.x) | для linking при разработке filter |
| Python 3 + dev | системный (3.12) | bindings (Phase 3) |
| Profiling | valgrind, gdb, strace, ltrace | debug-набор |
Что снаружи (на хосте)
Требуется:
- NVIDIA driver ≥ 555 (для CUDA 12.4)
- nvidia-container-toolkit
- Docker Engine с
--gpusподдержкой - Каталог
/run/cuframes(создаётся compose'ом с rw-доступом, либоsudo mkdir -p /run/cuframes && sudo chown $USER /run/cuframes)
Ограничения / нюансы
shm_size: 2gb—/dev/shmконтейнера, нужен для CUDA IPC handles и producer/consumer shared memory rings. Default 64 MB не хватит.ipc: shareable— позволяет связывать namespace с другими контейнерами черезipc: "container:cuframes-dev". Нужно для cross-container CUDA IPC.SYS_PTRACEcap +seccomp:unconfined— для gdb / strace inside. Снимать в production-builds.- Sysctl / ulimits — bind-mount файла
/etc/security/limits.confв init не гарантирует применения (зависит от docker config). Если CUDA-IPC дастEMFILE— поднять host-sideulimit -n 65536передdocker compose up.
Полезные команды (внутри контейнера)
# Build cuframes (когда появится CMakeLists.txt)
cmake -B build -S . -G Ninja
cmake --build build -j
# Run tests
ctest --test-dir build --output-on-failure
# Phase 0 spike измерения
./build/tools/spike/pingpong_producer cam_test &
./build/tools/spike/pingpong_consumer cam_test
Distribution / production images
Это dev-окружение. Production-images (для FFmpeg-with-cuframes-plugin,
Frigate drop-in) — отдельные Dockerfiles в docker/ffmpeg-cuframes/ и
docker/ffmpeg-cuframes-frigate/, появятся в Phase 4.