Hacker News Digest

• Arm Neural Technology — первое в мире решение, встраивающее нейро-акселераторы в мобильные GPU Arm. С 2026 г. оно сокращает нагрузку на GPU до 50 % и открывает путь к ПК-качеству графики на смартфонах.
• Neural Super Sampling (NSS) — стартовая функция: апскейл 540p → 1080p за 4 мс на кадр.
• Открытый набор разработчика уже доступен: плагин Unreal Engine, эмулятор Vulkan, профайлеры, модели на GitHub и Hugging Face. Поддержка от Epic, Tencent, NetEase и др.
• Расширения Vulkan добавляют «Graph Pipeline» для вывода нейросетей прямо в рендер-процесс.

• Идея: нейросеть превращает «сырую» графику в AAA-качество, экономя ресурсы инди-разработчиков.
• Для работы нужно много тренировочных данных, уникальных для каждой игры.
• Реализация может идти через расширения Vulkan/OpenCL, а не проприетарные API.
• В железе задействуются GPU, Tensor-cores, NPU (матричные ускорители с FP4/INT4).
• Arm анонсировала мобильный upscaler 540p→1080p за 4 мс, но чипы появятся лишь в 2026 г.

PCI-SIG анонсировала PCIe 8.0

• Пропускная способность вдвое выше PCIe 7.0: до 256 ГТ/с на линию.
• Технология: PAM4, 32 ГТ/с, 0,5 В амплитуда, < 1 Вт/лейн энергопотребление.
• Обратная совместимость с предыдущими поколениями.
• Спецификация выйдет в 2027 г., первые продукты — 2028–2029 гг.
• Цели: ИИ-акселераторы, HPC, NVMe-накопители, 800 Гбит/с сети.

• Кто-то предлагает «перевернуть» архитектуру: пусть GPU-PCB станет материнской платой, а CPU с памятью встаёт в PCIe-слот.
• Обсуждают, что PCIe-спецификация всегда на три поколения впереди реальных продуктов: сейчас в работе уже Gen 8.
• Пользователи жалуются на нехватку линий PCIe в десктопах и мечтают о GPU-сокете с собственными слотами RAM.
• EE и другие специалисты считают это скорее проблемой экосистемы и совместимости, чем чисто инженерной.
• Упоминают, что в дата-центрах (DGX, DPU, NVMe-«без-сервера») похожая идея уже реализована.

• У OpenAI десятки миллиардов долларов на кластеры GPU (по $20–40 тыс. за карту) и инфраструктуру, чего нет у обычного пользователя.
• Ключевая «фишка» — массовое батчирование запросов: одновременная обработка тысяч пользователей позволяет загружать видеопамять и вычислительные блоки почти на 100 %, тогда как дома GPU простаивает.
• Используются Mixture-of-Experts, спекулятивное декодирование, конвейерная разбивка модели по GPU и прочие оптимизации, снижающие затраты на одного пользователя.
• Большинство пользователей активны лишь доли процента времени, поэтому общая нагрузка оказывается меньше, чем кажется по 700 млн «weekly users».
• Всё это — классический эффект экономии масштаба: высокие фиксированные затраты и почти нулевые переменные на одного юзера делают запуск GPT-4 локально невыгодным.

Это вторая часть серии о разработке Tyr — современного GPU‑драйвера на Rust для ядра Linux с поддержкой Arm Mali на CSF.

Разберем, как работают GPU‑драйверы, на примере VkCube — простого приложения на Vulkan, рисующего вращающийся куб. Простота сцены помогает понять путь данных и команд от приложения к GPU.

UMD и KMD

• UMD (usermode) реализует API вроде Vulkan/OpenGL/OpenCL и преобразует команды приложений в низкоуровневые команды для GPU. В нашем случае это panvk из Mesa.
• KMD (kernel mode) соединяет UMD с железом: инициализирует устройство, управляет памятью, очередями, планированием и уведомлениями. В нашем случае это Tyr, нацеленный попасть в основное дерево Linux.

Что делает UMD

• Подготавливает данные: геометрию, текстуры, машинный код шейдеров, матрицы трансформаций.
• Просит KMD разместить их в памяти GPU, создает VkCommandBuffer с командами отрисовки, настраивает состояние конвейера, указывает, куда писать результат, и как получать сигнал о завершении.

Про шейдеры

• Это полноценные программы на GPU. Для VkCube им нужны хотя бы геометрия, цвета и матрица вращения, чтобы расположить и раскрасить куб и крутить его.

Что делает KMD

• Выделяет и отображает память, изолируя процессы в отдельных контекстах/VM.
• Принимает работу от UMD, ставит в аппаратные очереди, отслеживает зависимости и завершение.
• Планирует выполнение на массово параллельном, асинхронном железе, соблюдая порядок и справедливое распределение ресурса между клиентами.
• Инициализирует устройство: тактирование, питание, стартовые процедуры; обеспечивает совместный и честный доступ приложений к GPU.

Ключевой вывод

• Основная сложность — в UMD, который переводит высокоуровневые API в команды GPU. Но KMD обязан предоставить надежные примитивы: память, очереди, синхронизацию, планирование и разделение ресурсов, чтобы UMD было реально реализовать.

Интерфейс драйвера

• На основе этих задач KMD экспонирует минимальный набор операций: запрос сведений об устройстве, создание/уничтожение VM, привязка/отвязка памяти к VM, получение состояния VM, отправка работ в очереди и механизмы уведомлений — тот же API, что у C‑драйвера Panthor для того же железа.

• Обсуждение статьи о драйвере GPU: часть читателей хвалит материал, но считает его слишком коротким и ждёт продолжения/второй части.
• Уточняют, что речь идёт о драйвере panthor для Mali CSF (на RK3588), а не panfrost; один из комментаторов отмечал баги в Firefox на RK3588, ему ответили про соответствующий драйвер.
• Спор о фокусе: одни подчёркивают важность того, что это один из первых GPU-драйверов Linux на Rust; другие критикуют кликбейт заголовок и считают, что нужно акцентировать Mali CSF, а не Rust.
• Техническая дискуссия: вопрос о целесообразности uring_cmd вместо ioctl; ответы поясняют, что из-за природы асинхронных очередей GPU дополнительная CPU-очередь мало что даст, а интерфейс драйвера следует ожиданиям Mesa.
• Отмечают, что текущая часть охватывает в основном границу пользователь/ядро и управление очередями/буферами; «основное действие» — выполнение команд GPU — ожидается в следующих частях.
• Дополнительно подчёркивают сложность современных GPU-драйверов и их объём в ядре Linux, что оправдывает выбранные подходы и терминологию.