Hacker News Digest

NextSilicon представила новый процессорный чип, бросающий прямой вызов доминированию Intel и AMD на рынке процессоров. Компания, ранее не известная как крупный игрок в этом сегменте, теперь позиционирует себя как серьезного конкурента технологических гигантов. Хотя конкретные технические детали чипа в статье не раскрываются, это событие знаменует собой важный сдвиг в конкурентной ландшафте процессорной индустрии.

Появление NextSilicon на рынке может привести к усилению конкуренции и потенциальному снижению цен для потребителей. Компания, судя по всему, стремится занять нишу в сегменте, где до сих пор доминировали два основных игрока. Это развитие может стимулировать инновации как со стороны NextSilicon, так и со стороны Intel и AMD в ответ на новую угрозу.

• СервисеHome подчеркнул, что Maverick-2 — это не векторный, а data-flow процессор, что важно для понимания его позиционирования.
• Дискуссия показала, что сравнение с Anton, A64FX и другими архитектурами неуместно, так как они решают разные задачи.
• Участники отметили, что для Maverick-2 нужен JIT-подход к софту, а не переписывание существующего кода.
• Было отмечено, что в отличии от GPGPU, Maverick-2 не требует переписывания кода под CUDA/OpenCL модель, но вместо этого требует компиляции под его нативную модель.
• В конце обсуждение сошлось на то, что если рынок действительно нуждается в таком процессоре, то NEC или другой вендор мог бы его сделать, но это не делаеться, потому что это не их фокус.

• Япония продолжает финансировать Pezy Computing, создающую энергоэффективные математические ускорители SC4S/SC5, способные заменить GPU в HPC и ИИ.
• SC4S: 2 048 ядер, 8 TFLOPS FP64, 200 Вт, 40 нм; SC5: 16 384 ядер, 64 TFLOPS FP64, 400 Вт, 7 нм; оба используют SIMD и обходятся без HBM, охлаждаясь жидкостью.
• Ускорители уже стоят в 6-8 системах ТОП500; пиковая энергоэффективность 32 GFLOPS/Вт.
• Драйверы OpenCL/CUDA-аналог ZCL, компиляторы Fortran/C++ готовы; в 2026-2027 ждут SC6 (128 TFLOPS FP64, 7 нм) и SC7 (E级, 3 нм).
• Цель: 10× экономия энергии и долгая независимость от NVIDIA/Intel.

• Япония развивает собственные HPC-акселераторы (Pezy и др.), ориентированные на FP64 и традиционные суперкомпьютерные задачи, а не на ИИ-низкоточность.
• Эти чипы создаются под кластеры с жидкостным охлаждением и продаются не поштучно, а целыми стойками.
• Производительность FP64 у Pezy конкурентна с NVIDIA, но энергоэффективность и программное окружение NVIDIA пока непревзойдены.
• Японские компании и государство инвестируют в HPC-экосистему, чтобы сохранить технологический суверенитет и не зависеть от американских GPU.
• Участники обсуждают, насколько целесообразно переключение на альтернативные форматы чисел (posits) и почему правительства продолжают финансировать «собственных лошадей» несмотря на риск провала.

• Крис Латтнер (LLVM, Swift) делает новый язык Mojo, чтобы ML-код был быстрым и удобным.
• Проблема: GPU-ядра пишутся на CUDA/OpenCL вручную, медленно и зависят от одного вендора.
• Решение: язык с метапрограммированием и типами, который «знает» об аппаратуре и генерирует оптимальный код под любую платформу.
• Цель: один код → любой GPU/CPU, открытая экосистема, no lock-in.

• Mojo обещает «Python++, но быстрый», но до сих пор нет полноценных классов, а «полный суперсет» превратился в мягкое «всё ещё не Python».
• Лицензия проприетарная — для многих это стоп-фактор: «сделайте GPL или идите лесом».
• Экосистема Python неподвластна: все уже завязаны на PyTorch/CUDA, а Mojo пока не даёт причин мигрировать.
• Julia, Elixir/Nx, CuPy, Triton, Numba — всё уже умеют «быстро + GPU», без нового языка.
• Итог: Mojo выглядит технически интересным, но «ещё один закрытый язык» в 2025 году воспринимается как ненужный риск.

В декабре 2020-го Хектор Мартин запустил Asahi Linux, а я, работая над Panfrost, лишь хотел подсказать. В итоге купил Mac mini и начал реверсить GPU. Через пару недель нарисовал треугольник, потом — компилятор шейдеров, а после сессии за несколько дней поднял OpenGL-драйвер.

Год улучшал драйвер, пока игры не пошли под macOS. Параллельно Asahi Lina писала kernel-драйвер; в декабре 2022-го у нас впервые заработала графика в Linux.

В 2023-м, заканчивая универ, я решил:

• довести M1-драйвер до ума;
• сделать полноценный OpenGL 4.6 и Vulkan;
• запустить Proton-игры.

Через месяц после выпуска — OpenGL 3.1, затем ES 3.1. Добавил эмуляцию geometry/tessellation, в январе 2024-го сдал OpenGL 4.6. Vulkan 1.3 прошёл за пару недель, 1.4 вышел в день публикации спецификации. Karol Herbst добавил OpenCL 3.0. Подключил sparse-текстуры — заработал Direct3D 12 через Proton.

Цели выполнены: драйверы в Mesa, игры идут, миф о несовместимости Vulkan с Apple развеян.

• Alyssa за 5 лет с нуля довела Vulkan-драйвер для Apple Silicon до upstream, чем вдохновила всё open-source-сообщество.
• Учёба, работа в Collabora и «хобби»-проект — комментаторы поражаются, как она всё успевала.
• С августа она в Intel и, судя по резюме, занимается open-source-графикой Xe-HPG.
• Многие жалеют, что она уходит из Asahi, но считают переход новым вызовом, а не «уходом».
• Появились вопросы о будущем Asahi на M3/M4 и о том, почему Apple не мешает проекту, в отличие от других.

Это вторая часть серии о разработке 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, что оправдывает выбранные подходы и терминологию.