Спасибо за серию! Поделюсь результатом на смешанном комплекте: 2× CMP 50HX + CMP 90HX, два Xeon E5-2680 v4, Ubuntu 26.04, ядро 7.0.0-31, адаптированный смешанный драйвер NVIDIA 610.57.04. Compute unlock был сделан раньше; здесь проверяли PCIe, BAR1 и P2P.
Что получилось:
90HX: Gen1 x1 → Gen2 x1. RAM→GPU: 0,181 → 0,364 ГБ/с; GPU→RAM: 0,213 → 0,418 ГБ/с. Физическая ширина осталась x1.
BAR1 на всех трёх картах: 128/128/256 MiB → 16 GiB на каждой. Это окно доступа, не увеличение объёма VRAM. Понадобился DSDT override: прошивка не описывала уже настроенные процессорами окна MMIOH. Сам BIOS и MMIOH-регистры не меняли.
Между двумя 50HX заработал BAR1 P2P: 1,37 ГБ/с в обе стороны против 0,82–0,83 ГБ/с через RAM. Они уже были на Gen2 x4. Для этого адаптировали BAR1-путь из обсуждения CMP50HX, на которое выше сослался LoDo.
Проверяли и cudaMemcpyPeerAsync, и CUDA-ядро, читающее память соседней карты, с проверкой каждого элемента. Основной замер — 32 MiB, прогрев и медиана пяти повторов; отдельно прошёл новый процесс с 256 MiB и десятью повторами. В скорости пути через RAM полезный объём учитывался один раз, время — сумма обеих передач.
Самый неприятный нюанс оказался в загрузке смешанного комплекта. На этой машине повторный probe уже инициализированных 50HX после reload драйвера заканчивался отказом GSP. Помогло временно удержать обе 50HX через driver_override до первого probe, выполнить Gen2-процедуру с перезагрузками модуля на одной 90HX, а затем впервые подключить 50HX. Такая автозагрузка успешно прошла два раза.
А вот 50HX↔90HX через CUDA P2P не заработали: во всех четырёх направлениях canAccessPeer=0, а прямая попытка cudaDeviceEnablePeerAccess возвращает cudaErrorPeerAccessUnsupported (217). При этом nvidia-smi topo -p2p r рисует OK. Причину окончательно не установили, поэтому утверждать, что смешанный P2P физически невозможен, не буду.
Все три карты прошли 10 минут совместной нагрузки FP16/FP32 с проверкой результатов по CPU и 360 матричных тестов llama.cpp. Во время нагрузочных тестов — без ошибок данных и новых Xid/AER. Температуры максимум 55/53/66°C при лимитах 158/158/225 W. Это пока короткая проверка, не многосуточный тест стабильности.
Всего три видюхи, одна 90 и две 50
Спасибо за серию! Поделюсь результатом на смешанном комплекте: 2× CMP 50HX + CMP 90HX, два Xeon E5-2680 v4, Ubuntu 26.04, ядро 7.0.0-31, адаптированный смешанный драйвер NVIDIA 610.57.04. Compute unlock был сделан раньше; здесь проверяли PCIe, BAR1 и P2P.
Что получилось:
90HX: Gen1 x1 → Gen2 x1. RAM→GPU: 0,181 → 0,364 ГБ/с; GPU→RAM: 0,213 → 0,418 ГБ/с. Физическая ширина осталась x1.
BAR1 на всех трёх картах: 128/128/256 MiB → 16 GiB на каждой. Это окно доступа, не увеличение объёма VRAM. Понадобился DSDT override: прошивка не описывала уже настроенные процессорами окна MMIOH. Сам BIOS и MMIOH-регистры не меняли.
Между двумя 50HX заработал BAR1 P2P: 1,37 ГБ/с в обе стороны против 0,82–0,83 ГБ/с через RAM. Они уже были на Gen2 x4. Для этого адаптировали BAR1-путь из обсуждения CMP50HX, на которое выше сослался LoDo.
Проверяли и cudaMemcpyPeerAsync, и CUDA-ядро, читающее память соседней карты, с проверкой каждого элемента. Основной замер — 32 MiB, прогрев и медиана пяти повторов; отдельно прошёл новый процесс с 256 MiB и десятью повторами. В скорости пути через RAM полезный объём учитывался один раз, время — сумма обеих передач.
Самый неприятный нюанс оказался в загрузке смешанного комплекта. На этой машине повторный probe уже инициализированных 50HX после reload драйвера заканчивался отказом GSP. Помогло временно удержать обе 50HX через driver_override до первого probe, выполнить Gen2-процедуру с перезагрузками модуля на одной 90HX, а затем впервые подключить 50HX. Такая автозагрузка успешно прошла два раза.
А вот 50HX↔90HX через CUDA P2P не заработали: во всех четырёх направлениях canAccessPeer=0, а прямая попытка cudaDeviceEnablePeerAccess возвращает cudaErrorPeerAccessUnsupported (217). При этом nvidia-smi topo -p2p r рисует OK. Причину окончательно не установили, поэтому утверждать, что смешанный P2P физически невозможен, не буду.
Все три карты прошли 10 минут совместной нагрузки FP16/FP32 с проверкой результатов по CPU и 360 матричных тестов llama.cpp. Во время нагрузочных тестов — без ошибок данных и новых Xid/AER. Температуры максимум 55/53/66°C при лимитах 158/158/225 W. Это пока короткая проверка, не многосуточный тест стабильности.
я просил, год или два назад, но воз и ныне там
от случайного нажатия на крестик это не спасёт
состояние страниц сбросится
все процессы прервутся, если они были
А вы ассемблер сможете прочитать?
Получается если я не читал исходные коды браузера и ядра то всё?