Массив популяций занимает nx*ny*9*4 байта и показывался шейдеру одной привязкой. dzn объявляет max_storage_buffer_binding_size = 128 МиБ, поэтому потолок выходил 3.73 млн узлов: 14 прогонов кампании из 115 падали на создании bind group, а на них приходится 70.7% её стоимости. Ограничена при этом ровно привязка: max_buffer_size у dzn 2047 МиБ. Поэтому тот же буфер теперь показывается девятью привязками, по одному направлению в каждой, и потолок поднимается до 33.5 млн узлов — самая крупная сетка кампании (4096x4096, 16.8 млн) проходит с запасом. Как устроено: * шаг между направлениями выровнен на 256 байт (dir_stride), потому что смещение привязки обязано быть кратно min_storage_buffer_offset_alignment; * обращения к популяциям в WGSL идут через fget/fset/pget/pset, а их тело генерируется под вариант (build_shader); * вариант выбирается по max_storage_buffer_binding_size адаптера — где предела нет, собирается прежний общий, без switch в аксессорах; * KBC2D_SPLIT_POPULATIONS=1 включает раздельные принудительно: иначе сверить два варианта на одной карте нечем. Проверено: * на одном драйвере оба варианта дают одно и то же — Cd 2.39486, energy_end 5.74813e-05; раздельный стоит 5.7% пропускной способности; * на сетке 2048x2048, где раздельные привязки и нужны, нативный прогон против контейнерного: energy_end расходится на 2.4e-07, enstrophy_end на 1.3e-07; * preflight в контейнере: 115 сценариев из 115, ни одного отказа (было 14); * 29 собственных тестов решателя зелёные. Образ опубликован как notbigghost/kbc2d:1.2.0 (он же latest). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
98 lines
5.6 KiB
YAML
98 lines
5.6 KiB
YAML
# Развёртывание кампании на сервере с NVIDIA. Этот файл САМОДОСТАТОЧЕН: он тянет готовый образ
|
||
# из реестра и исходников репозитория не требует. Скопировать на сервер достаточно его одного.
|
||
#
|
||
# mkdir -p ~/kbc2d && cd ~/kbc2d
|
||
# curl -O <ссылка на этот файл> # либо просто перенести файл руками
|
||
#
|
||
# docker compose -f docker-compose.server.yml --profile check run --rm vulkan
|
||
# docker compose -f docker-compose.server.yml --profile check run --rm preflight
|
||
# docker compose -f docker-compose.server.yml --profile check run --rm calibrate
|
||
# docker compose -f docker-compose.server.yml --profile check run --rm plan
|
||
# docker compose -f docker-compose.server.yml up -d
|
||
# docker compose -f docker-compose.server.yml logs -f
|
||
#
|
||
# Порядок именно такой. Сначала vulkan: если карта не видна, кампания молча уйдёт считать
|
||
# ничего — точнее, откажется стартовать на первом же прогоне, но узнать об этом через час
|
||
# обиднее, чем через минуту. Потом preflight (каждый сценарий стартует на два шага), потом
|
||
# calibrate (замер MLUPS этой машины), и только потом сама кампания.
|
||
#
|
||
# Результаты складываются в ./out на хосте — около 4.4 ГБ гифок и рядов за полный проход.
|
||
|
||
name: kbc2d
|
||
|
||
# ── общая часть всех сервисов ────────────────────────────────────────────────
|
||
x-kbc2d: &kbc2d
|
||
image: notbigghost/kbc2d:1.2.0
|
||
pull_policy: missing
|
||
volumes:
|
||
- ./out:/work/bench/out
|
||
environment:
|
||
# ГЛАВНОЕ МЕСТО ВСЕГО ФАЙЛА. NVIDIA Container Toolkit подкладывает внутрь Vulkan-ICD
|
||
# (nvidia_icd.json) только если в этом списке есть `graphics`. С одним `compute` wgpu не
|
||
# увидит НИ ОДНОГО адаптера, и решатель откажется стартовать с --backend gpu. В образе
|
||
# значение уже прописано, здесь оно продублировано явно — чтобы его было видно тому, кто
|
||
# читает compose, а не Dockerfile.
|
||
NVIDIA_DRIVER_CAPABILITIES: compute,utility,graphics
|
||
NVIDIA_VISIBLE_DEVICES: all
|
||
# Оценки в часах драйвер считает из этих чисел. Умолчания взяты с другой машины —
|
||
# подставьте сюда то, что напечатает профиль calibrate.
|
||
KBC2D_GPU_MLUPS: ${KBC2D_GPU_MLUPS:-1200}
|
||
KBC2D_CPU_MLUPS: ${KBC2D_CPU_MLUPS:-22}
|
||
deploy:
|
||
resources:
|
||
reservations:
|
||
devices:
|
||
- driver: nvidia
|
||
count: all
|
||
capabilities: [gpu]
|
||
|
||
services:
|
||
# ── сама кампания: единственный сервис, который поднимается по `up -d` ──────
|
||
campaign:
|
||
<<: *kbc2d
|
||
container_name: kbc2d-campaign
|
||
# --resume пропускает всё, у чего уже есть summary.json: перезапуск продолжает с места,
|
||
# а не начинает заново. Именно поэтому перезапуск здесь безопасен и дёшев.
|
||
command: ["--resume"]
|
||
# on-failure, а НЕ unless-stopped: кампания завершается штатно с кодом 0, и политика
|
||
# «перезапускать всегда» после её окончания крутила бы контейнер вхолостую по кругу.
|
||
# Падение (OOM, перезагрузка хоста) даёт ненулевой код и будет подхвачено.
|
||
restart: on-failure:5
|
||
stop_grace_period: 30s
|
||
# Девяносто часов вывода — это сотни мегабайт журнала; без ограничения он съест диск.
|
||
# Полные логи каждого прогона всё равно лежат в out/<id>/log.txt.
|
||
logging:
|
||
driver: json-file
|
||
options:
|
||
max-size: "50m"
|
||
max-file: "5"
|
||
|
||
# ── проверки перед запуском (профиль check, сами не поднимаются) ────────────
|
||
vulkan:
|
||
<<: *kbc2d
|
||
profiles: ["check"]
|
||
entrypoint: ["vulkaninfo"]
|
||
command: ["--summary"]
|
||
|
||
preflight:
|
||
<<: *kbc2d
|
||
profiles: ["check"]
|
||
entrypoint: ["python3"]
|
||
command: ["preflight.py"]
|
||
|
||
calibrate:
|
||
<<: *kbc2d
|
||
profiles: ["check"]
|
||
command: ["--calibrate"]
|
||
|
||
plan:
|
||
<<: *kbc2d
|
||
profiles: ["check"]
|
||
command: ["--dry-run"]
|
||
# ── если результаты нужны не под root ────────────────────────────────────────
|
||
# Контейнер работает от root, поэтому файлы в ./out окажутся root:root. Чтобы они
|
||
# принадлежали вам, добавьте в x-kbc2d строку
|
||
# user: "${UID}:${GID}"
|
||
# и запускайте как UID=$(id -u) GID=$(id -g) docker compose -f … up -d
|
||
# (каталог ./out при этом должен быть создан заранее и принадлежать вам).
|