Hacker News Digest

Проект PS5LM запускает llama.cpp прямо на взломанной консоли PS5: языковая модель работает на GPU консоли через бэкенд Vulkan на чипе RDNA 2, получая 11,4 ГБ общей памяти под модель и контекст. Консоль превращается в приватный сервер моделей для всей домашней сети — без ПК, облака и аккаунтов. Она отвечает на OpenAI-совместимый эндпоинт /v1/chat/completions, на Anthropic-совместимый /v1/messages (с ним работает Claude Code) и на /v1/systemone для «решающих» моделей вроде d1, Clef и OpenJev, выдающих типизированные решения с калиброванными вероятностями за доли секунды.

Интерфейс выведен на телевизор: каждый запрос стримится как чат с указанием устройства и текста ответа, кнопка «квадрат» запускает демо, «треугольник» открывает клавиатуру — всё управляется с дивана. Отдельная страница следит за температурой, энергопотреблением и загрузкой GPU и CPU за последние две минуты или час. Планировщик сам подбирает для каждого GGUF-файла максимальный контекст и лучший кэш под свободную память, а список Suggested содержит модели, измеренные на консоли. Поддерживаются все архитектуры и квантования, известные llama.cpp. Проект распространяется под GPL-3.0, не содержит файлов SDK Sony, ключей, прошивок и весов моделей и не связан с Sony Interactive Entertainment.

Запуск llama.cpp на взломанной PS5 технически возможен, но модель Qwen 3.8 27B в 2‐битной квантизации работает медленно и хуже, чем современные сервисы. Хостинг проекта на GitHub повышает риск DMCA, поэтому рекомендуется дублировать репозиторий. Для практических задач лучше использовать более мощные GPU или хотя бы 4‐битную квантизацию. Спор: Rabbit504030201 считает, что проект не должен размещаться на GitHub из‐за риска DMCA от Sony; dewey и другие указывают, что GitHub обеспечивает видимость и возможность зеркалирования; minimaxir предупреждает, что даже кастомный домен не спасёт от takedown. Несколько комментаторов согласны, что взломанная PS5 может стать недорогим вычислительным узлом — цена в $650 сопоставима с бюджетными видеокартами, но её аппаратные возможности уступают специализированным GPU. Модель Qwen 3.8 27B в 2‐битной квантизации на PS5 работает значительно медленнее и менее качественно, чем Claude или Opus 5.5: токен‐пропускная способность низкая, ответы требуют десятки тысяч токенов. Совет: Для улучшения качества вывода рекомендуется использовать 4‐битную квантизацию вместо 2‐битной — она ближе к полной точности и даёт более приемлемую производительность. PS5 подходит для длительных задач с низкой требовательностью к интеллекту: мониторинг серверных ошибок, просмотр видеонаблюдения, управление поливом растений. Спор: shiftpgdn предлагает использовать дешёвые платы BC250 за $150‐200; haunter возражает, что за такие деньги выгоднее купить RTX 3060 — получив более надёжную и гибкую платформу. Совет: Чтобы снизить риск удаления проекта, следует зеркалировать репозиторий не только на GitHub, но и на альтернативных хостингах или собственных доменах, как советует dewey.

Тимур Кристоф из команды Valve по Linux-графике за год значительно улучшил поддержку старых AMD GPU (GCN 1.0/1.1) в ядре Linux через AMDGPU-драйвер. Его работа позволила перевести эти карты с устаревшего Radeon-драйвера на современный стек, что открыло доступ к RADV Vulkan, повысило производительность и исправило проблемы с управлением питанием и дисплеем. Особенно ценным стал вклад в реализацию soft reset и других низкоуровневых улучшений, сделав десятилетние карты пригодными для Linux-игр в 2026 году и позже.

Ранее AMD почти не уделяла внимания этим архитектурам, но усилия Кристофа компенсировали этот пробел. Как показал релиз Linux 6.19, переход на AMDGPU дал почти 30% прирост производительности для старых Radeon GPU. Его доклад на XDC2026 в Торонто подробно освещает путь от работы в пользовательском пространстве (Mesa) к ядру и практическое влияние на сообщество пользователей legacy-оборудования. Эти изменения делают Linux более жизнеспособной платформой для старых AMD-устройств без необходимости апгрейда.

Работа Тимура Кристофа значительно улучшила жизнеспособность старых AMD GPU под Linux, обеспечив стабильную производительность в играх и GPGPU-нагрузках. Это стало возможным благодаря открытому стеку AMD и вкладу Valve в экосистему. Пользователи отмечают, что старые GPU, такие как HD 7800/7900, теперь работают лучше под Linux, чем под Windows, благодаря переходу на драйверы AMDGPU и RADV Vulkan, что делает их привлекательными при высокой стоимости нового железа. Опыт использования Steam Deck и аналогичных RDNA 2 GPU подтверждает, что Linux часто превосходит Windows в игровой производительности, особенно для не-AAA проектов. Открытость стека AMD и поддержка Mesa позволяют энтузиастам улучшать драйверы, в отличие от NVIDIA, чей Vulkan-стек на Linux менее эффективен из-за закрытости. Рекомендуется покупать старые среднебюджетные GPU для Linux: их драйверы прошли годы QA, оптимизированы в дистрибутивах и не требуют ожидания обновлений ядра. Эти карты полезны не только для игр, но и для GPGPU, кодирования/декодирования видео, дополнительных мониторов, виртуализации и как резервные устройства, продлевая их жизненный цикл. Однако некоторые пользователи опасаются, что даже незначительные изменения в драйверах для устаревших GPU могут нарушить стабильность в продакшен-средах из-за ограниченного тестирования на малом числе оставшихся пользователей. Для LLM-инференса старые GPU неэффективны из-за отсутствия аппаратной поддержки FP8/FP4 и малого объёма VRAM, даже при использовании квантованных моделей, уступая облачным решениям. Вклад Valve в драйверы AMD считается критически важным: он дополняет и улучшает собственные усилия AMD по ROCm, OpenCL и Vulkan, и сообщество призывает к дальнейшему сотрудничеству.

Выпуск Zig 0.17.0 стал результатом пяти месяцев работы 206 участников и 925 коммитов. Ключевое улучшение — переработка системы сборки с внедрением Build Server Protocol, что упрощает интеграцию с IDE и ускоряет разработку. ELF-линкер значительно улучшен, что делает инкрементальную компиляцию надёжной для всех пользователей на x86_64-linux. Обновлён уровень поддержки платформ: добавлен Tier 1 для Windows на ARM64, расширена поддержка Linux на RISC-V и улучшена работа на macOS. В языке удалён синтаксис умножения массивов, добавлены функции @bitCast с улучшенной безопасностью, @divCeil для точного округления вверх, @backingInt и @fromBackingInt для работы с перечислимыми типами, а также @SpirvType для Vulkan-разработки. Грамматика языка теперь формально специфицирована и протестирована фаззингом, что повышает надёжность парсинга. Перевод C-кода вынесен во внешний пакет, упрощая основной инструментарий. Zig остаётся ориентированным на создание надёжного, производительного и переиспользуемого кода, а развитие финансируется через Zig Software Foundation. Поддержка проекта через пожертвования помогает ускорить путь к версии 1.0.

Zig 0.17.0 — значительный шаг вперёд в интеграции с IDE и стабильности сборки благодаря Build Server Protocol и улучшенному ELF-линкеру, подтверждённому практическим опытом. Однако остаются споры: жёсткая политика против ИИ в репозитории критикуется за баны за личные проекты, хотя команда утверждает, что блокировки касаются только официальных пространств и могут быть ошибочными. Нестабильность сборок из-за изменений в build.zig между версиями признаётся, но некоторые считают её неизлемой ценой быстрого развития. Zig называют наиболее продуманным языком для человека по сравнению с C, Go и Haskell, несмотря на малую экосистему. Поддержка целевых платформ остаётся сильной стороной, сравнимой с C, особенно для SPIR-V и WebGPU. Векторизация циклов по-прежнему отключена из-за сложностей с LLVM, что разочаровывает разработчиков численных задач. Поддержка io_uring отсутствует в 0.17.0 — команда отказалась от реализации на последнем этапе, вызывая недовольство у тех, кто нуждается в асинхронном вводе-выводе. Несмотря на официальную политику против ИИ, Zig привлекателен для LLM-ассистированных задач из-за хорошей поддаче генерации и анализу кода. Пользователи советуют избегать слишком новых релизов в продакшене из-за риска поломки build.zig, рекомендуя фиксировать зависимости или использовать стабильные версии. Баны за ИИ часто ошибочны — рекомендуется обращаться в команду по email. Сообщество видит Zig как «живой» язык с быстрыми изменениями и энтузиазмом, похожим на ранние Node.js или ES6, привлекающим тех, кто готов к нестабильности. Сомнения в достижении 1.0 до 2028 года coexist с надеждой, что стабилизация IR и работа над проверкой жизненного цикла памяти могут ускорить релиз.

OpenDLSS-NR — это Vulkan-реализация нейросети DLSS 5 Neural Rendering от NVIDIA, бит-в-бит идентичная оригиналу. Она воспроизводит ту же архитектуру: U-Net из 71 блока Swin/Vit-трансформеров с глобальным ViT внизу, работающий в FP8 (E4M3) с FP16 накоплением, используя 141 МБ весов. Это генеративная нейросетевая отрисовка (Neural Rendering), которая не увеличивает разрешение, а улучшает уже отрисованный кадр: добавляет детали из шума, корректирует тон, структуру и кожу под стилем, принимая на вход текущий кадр (LDR-прокси), три канала гауссовского шума, репроецированный предыдущий вывод и пять скалярных условий, выдавая RGB-резидуал и логит временного смешивания. Все промежуточные результаты на 75 границах блоков совпадают с оригиналом байт в байт.

Есть независимый порт в браузере через WebGPU (ports/browser-webgpu/), который воспроизводит те же байты без tensor-ядер и FP8 — чисто на шейдерах. Для запуска нужны собственные веса в указанной структуре каталога. Сборка выполняется через PowerShell-скрипты: установка инструментов, сборка шейдеров и PTX, сборка демо на базе Filament. Демонстрация позволяет выбирать сцены из build\scenes и управлять через view.json. Производительность на RTX 4070 SUPER: от 2.8 мс при 768×768 до 29.3 мс при 3840×2160 (241 диспатч на кадр). Доступны переменные окружения для тонкой настройки: маска цепочки экспертов (DLSS5VK_CHAIN_MASK), порог отложенного слияния GEMM (DLSS5VK_DEFER_MAX), валидация и отладка. Проект лицензирован под MIT, не связан с NVIDIA и не предоставляет веса — пользователь отвечает за их законное получение и использование. Полная документация по сети, нумерации, исполнению и кадровому буферу находится в папке docs/.

OpenDLSS-NR воспроизводит архитектуру DLSS 5 бит-в-бит, но её практическая применимость ограничена высокой вычислительной нагрузкой — даже на флагманских GPU. Производительность сопоставима с оригиналом: на RTX 5060 в 1080p — 9.9 мс, на RTX 5090 в 2160p — 8.2 мс, что делает её непригодной для игр при 60+ FPS без топового железа. DLSS 2 и новее используют универсальную модель, персонализация достигается через настройки интенсивности и маскирование объектов на этапе инференса. Веса модели не включены в репозиторий, вероятно, из-за юридических рисков, несмотря на то, что по закону США они не подлежат авторскому праву как результаты работы нейросети. Документация содержит фактические ошибки, например, ложные утверждения о git-игнорировании файлов, которые на самом деле присутствуют в репозитории. Для практического использования требуется доступ к весам, извлечённым из последней версии DLSS 5 в игре NBA — без них проект неполноценен. Реализация использует одностадийную диффузионную модель в пиксельном пространстве — техническое достижение, несмотря на низкую производительность. Она больше похожа на технический демо-проект, чем на рабочее решение для игр — официально доступна только в одной игре. Архитектура включает 71 блок Swin/ViT-трансформеров, работает в FP8 (E4M3) с FP16 накоплением, соответствует описанию оригинальной модели NVIDIA. Временной путь использует репроецированный предыдущий кадр и логиты смешивания для стабильности — критично для устранения артефактов в динамических сценах. Оригинальный DLSS 5 использует дополнительные данные от движка (LOD, UV-карты), но OpenDLSS-NR, вероятно, обходит это, чтобы работать с существующими хуками без изменений рендерера. DLSS 1 использовал персонализированные модели на игру; с DLSS 2 NVIDIA перешла на универсальные — подтверждено техническими отчётами. Споры: некоторые считают, что LLM могли сгенерировать код и документацию, снижая доверие; другие утверждают, что если код работает — это не важно, кто его написал. Также обсуждается, использует ли сеть z-буфер: объясняют, что глубина уже закодирована в RGB-каналах, а добавление z-буфера увеличивает пропускную способность без значимой выгоды. NVIDIA не поддерживает открытые реализации CUDA; несмотря на позиционирование как сторонник open source, её интересы ограничены областями, где она сохраняет контроль. Создание OpenDLSS-NR требует глубокого понимания нейросетевых архитектур и может быть выполнено с помощью современных LLM, что снижает барьер для реверс-инжиниринга закрытых систем.

Проект на GitHub позволяет запускать Command & Conquer: Generals – Zero Hour на macOS, iPhone и iPad без эмулятора, используя оригинальный движок EA, распространяемый под лицензией GPL v3 через GeneralsX. Для рендеринга применяются DXVK и MoltenVK, что обеспечивает совместимость с Vulkan‑API на macOS и iOS. Репозиторий не содержит игровых артефактов – пользователь должен самостоятельно предоставить их. Контролы адаптированы под тач‑интерфейс, позволяя управлять юнитами и строить зданиями лишь пальцами. Система автоматически масштабирует UI под разные разрешения мобильных устройств, а поддержка как Apple Silicon, так и старых Mac гарантирует широкую совместимость.

Тесты показывают, что игра работает стабильно со скоростью около 60 fps на iPhone 13 Pro, а на Apple Silicon‑устройствах — без заметных задержек. Лицензия GPL v3 гарантирует открытый исходный код, что позволяет сообществу модифицировать и улучшать проект. Разработчики уже выпустили патчи, адаптирующие тач‑управление под жесты выбора юнитов и построения зданий, и планируют добавить поддержку внешних контроллеров. В репозитории также есть скрипты для автоматической упаковки необходимых ресурсов и запуска игры через простую CLI‑утилиту, упрощающую установку даже для новичков.

• Порт C&C Generals на iOS/iPad выполнен с помощью AI, но большую часть работы уже сделали предыдущие форки.
• В репозитории лишь небольшое количество изменений (около 19 из 2000 коммитов), остальные части уже были реализованы ранее.
• AI‑тексты иногда раздражают, но процесс в целом работает и позволяет оживить старую игру.
• Есть ограничения: проблемы с памятью iOS, необходимость собственного копирования игры и потенциальные баги/юридические вопросы.

FEX-Emu — быстрый эмулятор пользовательского режима x86 и x86-64 для Linux, позволяющий запускать x86-приложения на ARM64-устройствах. Он обеспечивает широкую совместимость с 32- и 64-битными бинарными файлами и может использоваться совместно с Wine/Proton для запуска Windows-игр. Эмулятор поддерживает перенаправление вызовов API в библиотеки хост-системы (OpenGL/Vulkan) для снижения накладных расходов, а также экспериментальный кэш кода для минимизации зависаний в играх.

В основе FEX лежит продвинутый бинарный рекompiler, поддерживающий все современные расширения набора инструкций x86(-64), включая AVX/AVX2. Используемая в нем собственная промежуточная репрезентация (IR) позволяет генерировать более оптимизированный код, чем традиционный splatter JIT. Модульная архитектура включает в себя комплексный слой трансляции системных вызовов, реализующий даже нишевые возможности вроде seccomp, и позволяет использовать FEX как бэкенд WoW64/ARM64EC в Wine.

• FEX позволяет запускать x86-64 игры на ARM64-устройствах, используя Wine/Proton, но сталкивается с проблемами совместимости из-за различий в модели памяти и DRM.
• Valve спонсирует FEX, что может быть частью стратегии по переходу игровой экосистемы на ARM.
• Проблемы с DRM и анти-чит системами, а также с производительностью графических API, таких как DirectX, которые не могут быть напрямую перенаправлены на хост-систему.
• Несмотря на это, FEX демонстрирует высокую производительность и совместимость с большинством игр, включая Cyberpunk 2077.
• Возможность запуска Windows игр на ARM64-устройствах с помощью FEX и Wine/Proton может быть ограничена из-за отсутствия поддержки ARM ноутбуков и отсутствия графических драйверов.

Khronos одобрила расширение GL_EXT_mesh_shader для OpenGL, и это первый шаг к полному Mesh Shaders в линейке Mesa. Реализация уже влили в mesa, а вот драйвер RadeonSI ждёт своей очереди. Релиз ожидается в ближайшие дни.

Это первая крупная фича для OpenGL за долгое время, и она привнесёт геометрические шейдеры в core Mesa. Работа велась под эгидой AMD, при поддержке Qiang Yu и Shihao Wang.

• Обсуждение в основном вращается вокруг будущего OpenGL и его расширений, включая GL_EXT_mesh_shader и GL_EXT_descriptor_buffer, а также их влияние на Minecraft и другие проекты.
• Участники обсуждают, что новые расширения делают возможным использование шейдеров накладки и дескрипторов буферов, что может быть полезно для таких проектов, как Minecraft.
• Также обсуждается, что OpenGL всё ещё используется в Minecraft и других проектах, и что новые расширения могут помочь в разработке игр.
• Некоторые участники выражают обеспокоенность по поводу того, что OpenGL может быть вытеснен Vulkan и другими API, и что поддержка OpenGL может быть прекращена в будущем.
• В обсуждении также затрагиваются такие темы, как эволюция графических API и их влияние на разработку игр и будущее OpenGL.

Создание кластера из 10 Raspberry Pi CM5 за $3000 оказалось спорным решением. Хотя сборка обеспечила 160 ГБ оперативной памяти и 10-кратный прирост производительности в тесте HPL (325 Gflops при 130 Вт), энергоэффективность лишь ненамного превзошла более мощный кластер на базе Framework. Основная проблема — неспособность использовать iGPU для ускорения AI через Vulkan в llama.cpp, что ограничило инференс моделей медленными CPU. Попытка запуска крупной модели Llama 3.3:70B провалилась: кластер не справился даже с генерацией 16 токенов из-за архитектурных ограничений распределённой обработки.

Практический вывод: такие системы подходят лишь для узких сценариев параллельных вычислений, но бесполезны для современных AI-задач. Автор отмечает, что за два года ожидания поставки железо устарело, а альтернативы вроде Xerxes Pi на Kickstarter лишь повторяют эту рискованную модель.

• Сборка кластера из Raspberry Pi рассматривается как дорогостоящее и непрактичное, но интересное для обучения и экспериментов хобби, а не как эффективное решение для высокопроизводительных вычислений.
• Для серьёзных задач ИИ и распределённых систем рекомендуется использовать мощные CPU/GPU, виртуализацию или аренду облачных ресурсов, а не низкопроизводительные одноплатные компьютеры.
• Кластеры на Raspberry Pi могут быть полезны для образовательных целей, тестирования программных интерфейсов (например, MPI, Kubernetes) и управления лёгкими контейнерами, но не для нагрузок, требующих высокой пропускной способности или вычислений.
• Экономическая нецелесообразность сборки кластера из Pi для производительности подчёркивается высокой стоимостью, низкой эффективностью и доступностью более мощных и дешёвых альтернатив (например, GPU, NUC, MacBook).
• Автор исходного обсуждения получил ценный опыт и материалы для контента, но проект не оправдал ожиданий по производительности, особенно в задачах LLM-инференса.

В декабре 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 не мешает проекту, в отличие от других.