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 — в следующих коммитах).
18 lines
503 B
Plaintext
18 lines
503 B
Plaintext
[consumer] key=A-4k30 count=600
|
|
[consumer] connected, 3840x2160 sync=stream
|
|
|
|
=== cuframes spike-v2 summary ===
|
|
scenario: A (stream sync)
|
|
frames received: 600
|
|
duration: 19.9625 s
|
|
effective fps: 30.0563
|
|
skipped (caught up): 0
|
|
TORN FRAMES: 0 ← ✓ clean
|
|
|
|
latency consumer-receive-to-kernel-done (microseconds):
|
|
mean: 164 us
|
|
p50: 145 us
|
|
p95: 206 us
|
|
p99: 606 us
|
|
max: 4412 us
|