Nvidia годами была «королём GPU», а центральные процессоры для дата-центров оставались вотчиной Intel и AMD. На GTC 2026 это закончилось: компания впервые всерьёз представила собственный серверный CPU Vera — и это прямой заход на чужую поляну.
Против всех правил рынка. Intel и AMD давно ушли в чиплеты, нарезая процессор на множество мелких кристаллов ради плотности ядер. Nvidia пошла ровно наоборот и собрала монолитный кристалл: 88 кастомных ядер Olympus, 176 потоков, 164 МБ общего L3-кэша, 1,2 ТБ/с памяти LPDDR5X и когерентную связь с GPU до 1,8 ТБ/с по NVLink-C2C.
Ставка на скорость одного ядра. Пока конкуренты гнались за числом ядер, ядро Olympus заточено под быстрый одиночный поток: 10-широкий декодер, агрессивная переупорядочка команд, префетчер под «прыжки по указателям». Nvidia заявляет около +50% производительности к x86, ×1,5 IPC, втрое больше пропускной способности памяти на ядро и вдвое выше энергоэффективность.
Почему именно сейчас. «ИИ требует новый процессор: агентный ИИ снова вывел CPU на критический путь», — объясняют в Nvidia. ИИ-агенты выполняют ветвистую, плохо распараллеливаемую логику, где решает не общая пропускная способность, а скорость единичного потока — как раз то, во что метит Olympus. Vera уже в серийном производстве и стоит у OpenAI, Anthropic, SpaceX, Google Cloud, Azure, Oracle и CoreWeave.
Часть большего. Vera — лишь один из семи со-спроектированных чипов платформы Vera Rubin. Nvidia обещает до 10× больше токенов на мегаватт и кратное падение цены за миллион токенов относительно прошлого поколения. Аналитики называют это «предельным ко-дизайном как оружием» — и, возможно, следующей историей роста Nvidia уже не в графике, а в процессорах.
Для ЛЛ: авторы текстов «350 нм идеальное решение для всего» отстали от реальности на 20 лет. На днях к применению в космонавтике официально сертифицированы процессоры Intel на технологии 1.8 нм (техпроцесс Intel 18A).
В старом тексте про то, что «российский» (по факту, скорее, белорусский) станочек для производства микросхем с характеристиками «350 нм», стоящий на складе под чехлом, без расходников, без трафаретов, без персонала, без помещения для установки, скорее всего, сгниет так же, как сгнили станки 130 нм с завода Fab 38, купленные в 2006 году у AMD, появился очередной комментатор с мнением вида «350 нм – то, что надо для космоса, военных, электроники автомобилей, и стиралок».
Как легко было узнать, до последней блокировки Гугла, на Марсе успешно работает техника на процессоре Qualcomm Snapdragon 801. Процессор из 2013 года, технология 28 нм. И ничего, долетел до Марса, работает.
Поверхность Марса подвергается воздействию высоких уровней радиации, так как планета лишена глобального магнитного поля, а её атмосфера слишком тонка. Средняя доза радиации составляет около 0,7 миллизиверта (мЗв) в сутки. Это сопоставимо с дозой, которую космонавты получают на Международной космической станции (МКС), и примерно в 20–40 раз выше естественного фона на Земле
Как легко было узнать, до блокировки Гугла, в 2001 году был представлен «космический» процессор Bae (IBM) RAD750, выпускаемый по технологиям 250 и 150 нм.
Как легко было узнать, до блокировки Гугла, в 2016 году был представлен «космический» процессор Bae (IBM) RAD5500, выпускаемый по технологиям 45 нм.
На днях к применению в космонавтике официально сертифицированы процессоры Intel на технологии 1.8 нм (техпроцесс Intel 18A)
Согласно документации на сайте Intel, техпроцесс Intel 18A официально сертифицирован для использования в космической отрасли. Был опубликован документ (ранее остававшийся незамеченным), в котором описывается новое поколение процессоров Starfire, созданных по технологии 18A и предназначенных для работы в космосе. Intel представила две модификации чипов для орбитальных вычислительных систем; каждая из них представляет собой восьмиядерную однокристальную систему (SoC), включающую четыре ядра P-Core и четыре ядра LPE-Core. Одна версия оптимизирована для работы с низким энергопотреблением (тактовые частоты настроены на эффективность), тогда как вторая ориентирована на высокую производительность. В энергоэффективной версии частота ядер P-Core составляет 1,0 ГГц, а ядер LPE-Core — 850 МГц. В версии, ориентированной на производительность, Intel повысила частоту ядер P-Core до 3,1 ГГц, а ядер LPE-Core — до 2,1 ГГц.
Инженерное решение Intel по размещению CPU и NPU на передовом узле 18A, а GPU — на более зрелом узле Intel 3, аналогично подходу, примененному в серверном процессоре Clearwater Forest (288-ядерный Xeon). Использование наиболее современных транзисторов для космических задач обусловлено тем, что меньший размер элементов приводит к снижению заряда на бит памяти, что повышает чувствительность кремния к радиационным сбоям. Для компенсации этого фактора Intel применяет технологию RibbonFET и методы защиты архитектуры на уровне проектирования, вместо использования более толерантных к радиации старых техпроцессов.
Дополнительно, буквально «на днях» Интел решила проблемы с выпуском по этой технологии
Аналитики BlueFin Research Partners опубликовали отчет, в котором утверждается, что компания Intel в значительной степени — если не практически полностью — решила проблемы с выходом годной продукции, затрагивавшие ее техпроцесс с нормами 1,8 нм (официально именуемый Intel 18A) в прошлом году и в первые месяцы текущего года. Вероятно, именно эти проблемы стали причиной задержки выпуска процессоров Panther Lake (которые, согласно прежним планам, должны были выйти еще в прошлом году), а также их ограниченной доступности после релиза. Intel также наращивает изначально ограниченные производственные мощности для техпроцесса 18A. По данным BlueFin Research Partners, производство сейчас ведется на двух предприятиях: Fab 52 в Аризоне и еще одной площадке (предположительно в Орегоне — вероятно, D1X, которая также служит центром разработки компании). На обеих линиях в настоящее время увеличиваются объемы выпуска; целевой показатель для каждой из них составляет от 12 000 до 15 000 кремниевых пластин в месяц. Таким образом, суммарная производственная мощность Intel по техпроцессу 1,8 нм (18A) достигнет 24 000–30 000 пластин в месяц. https://www.hwcooling.net/en/intel-reportedly-solves-the-yie...
Ранее я часто рассказывал об особенностях видеокарт из 90-х. В рамках прошлых статей, мы успели с вами рассмотреть внутреннюю архитектуру 3dfx Voodoo, узнать о кастомном графическом API в S3 ViRGE, и даже написать свою собственную небольшую демку под видеокарты из 90-х. Вместо рассказов о GeForce 256 и ATi 3D Rage, в сегодняшнем материале мне хотелось бы поговорить о видеокарте, которая обогнала своё время — и при этом всё равно провалилась. Как вы уже поняли — речь пойдет об Intel i740.
Каким был первый GPU от Intel, на что он был способен и в чём заключается его главная тайна — читайте в сегодняшней статье!
❯ Предисловие
История видеоускорителей Intel начинается, как это ни странно, с программ космических симуляций. Первые наработки 3D-ускорителей разрабатывали ещё в 70-х годах в стенах компании GE Aerospace, однако в 1992 году, General Electric решили продать своё аэрокосмическое подразделение компании Martin Marietta, которое в 1995 году стало называться Lockheed Martin. После появления PlayStation 1 и массовых игровых автоматов с 3D-графикой, было очевидно что рано или поздно 3D станет мейнстримом и в сегменте домашних компьютеров, а пока конкуренция была ещё достаточно мала, Lockheed Martin решила организовать подразделение под названием Real3D.
По сути, в 1995 году из конкурентов у Real3D была только Nvidia со своим мультимедийным акселлератором NV1 и... PowerVR с GPU Midas 3. Но NV1 не был просто 3D-ускорителем — это целый комбайн, который включал в себя контроллер геймпадов от SEGA Saturn, звуковую карту, 2D-ускоритель для GDI/DDraw-игр и, собственно, 3D-ускоритель. Стоил NV1 целых 300$ и его самая главная фишка в лице 3D-ускорителя оказалась полным провалом: дело в том, что по каким-то причинам инженеры Nvidia решили построить растеризатор на базе квадов, а не общепринятых треугольников. Из-за этого разработчикам приходилось серьезно переписывать рендереры своих игр, поэтому на NV1 вышло всего 6 игр. Кроме того, NV1 оперировал не классическими UV-координатами, а специальными «весами», которые диктовали GPU как правильно наносить текстуру на примитив.
Как и NV1, PowerVR Midas 3 был тоже прорывным и в некоторой степени экзотическим GPU. В отличии от чипа от Nvidia, он оперировал классическими треугольниками, однако растеризатор здесь работал по принципу TBDR — Tile Based Deffered Renderer. Если говорить простыми словами, то видеокарта разбивала экран на набор тайлов размером 32x32 каждый, считала видимость и перекрытие всех рисуемых в тайле треугольников и затем отсылала их растеризатору. Таким образом, Midas 3 очень сильно экономил филлрейт за счёт отсечения невидимых поверхностей, не требовал тяжелого Z-буфера и заметно снижал нагрузку на общую шину с видеопамятью. Однако TBDR очень не любит полупрозрачные поверхности, а также геометрию с альфа-тестом, поэтому производительность Midas 3 значительно падала при отрисовке заборов, решеток и прочих объектов с полностью прозрачными пикселями. К слову TBDR в отличии от квадов живёт и сегодня и применяется даже в вашей RTX5090, а GPU от PowerVR сильно повлияли на успех первых iPhone (причём MBX был прямым наследником Midas 3).
Поэтому в 1995 году, Real3D совместно с Intel и Chips (читатели, заставшие 386/486, сразу поймут что это за компания) начали разрабатывать потребительский GPU под кодовым именем Auburn. Главной фишкой Auburn была новая шина AGP, созданная специально для видеокарт. Концептуально и электрически AGP был практически идентичен PCI: использовалась всё та же параллельная шина (за исключением того, что AGP не делил линии с другими устройствами как PCI) с теми же логическими уровнями, на программном уровне AGP-устройства использовали регистры PCI-контроллера и PCI-й же Configuration Space, а регистры и память самого GPU точно также маппились в адресное пространство процессора с помощью MMIO. Однако AGP добавлял ещё несколько важных фишек:
Возможность передачи данных как по восходящему, так и по спадающему фронту — как в DDR. Это позволяло передавать данные в два раза быстрее без фактического увеличения скорости шины, которая в первых версиях работала на частоте в 66МГц — x2 от PCI.
Технология GART, позволявшая замаппить кусок RAM для совместного использования GPU и CPU. Таким образом, GPU мог читать текстуры не только из собственной видеопамяти, но и из оперативной — что по теории Intel должно было решить проблему недостатка дорогой EDO-памяти для текстур и заметно удешевить видеокарты.
Иллюстрация с сайта pctechguide. Как мы с вами видим, процессор был связан напрямую с северным мостом, который включал в себя контроллер DRAM, PCI и AGP. Процессор был подключен к «северу» с помощью шины FSB
Как вы уже могли понять, основной упор в Auburn решили сделать на поддержку технологии GART. Суть её была такой, что на видеокарте располагается лишь минимальный объём видеопамяти (~4МБ) для хранения фреймбуфера и Z-буфера, в то время как для хранения текстур предполагается использовать системную память. Теоретически этот способ помогал заметно разгрузить шину GPU — VRAM в процессе растеризации, при этом распараллеливая обращения к текстурам через контроллер памяти в северном мосту. На бумаге это звучало хорошо...
❯ Разбираем архитектуру
Архитектура видеокарт в 90-х заметно отличалась от современных. Во первых, в GPU тех лет конвейер был фиксированным: все возможные операции по освещению, наложению тумана и текстурированию были заранее реализованы в железе и возможности вручную посчитать цвет фрагмента не было. Некоторым подобием шейдеров была возможность мультитекстурирования, которая позволяла за один проход наносить несколько текстур одновременно с разными операциями: например можно было наложить основную текстуру, маску и сферическую карту отражений, что позволяло сделать модельку машины, где кузов отражается, а матовые элементы — нет. Первой видеокартой с поддержкой мультитекстурирования была 3dfx Voodoo 2, однако там возможность нанесения нескольких текстур за один такт зависела от числа TMU — текстурных юнитов на видеокарте.
Иллюстрация с сайта ScienceDirect. Здесь представлен чуть более поздний конвейер — времен GeForce 256, с аппаратным T&L
Во вторых, вплоть до GeForce 256 в видеокартах вообще не было вершинного конвейера. Вы же помните слова о том, что видеопамять используется только для фреймбуфера, а оперативная — для текстур? Так вот, в те годы видеокарты не хранили в себе геометрию и никак её не обрабатывали, ожидая на вход уже готовые и преобразованные треугольники. Таким образом, вся нагрузка по трансформации треугольников, перспективному делению, повершинному освещению и клиппингу (разбиения частично видимых треугольников «перед носом» на несколько более мелких) ложилась на центральный процессор, в то время как GPU оставалось лишь это всё растеризовать (и именно отсюда растут корни glBegin/glEnd). В GF256 уже появилась поддержка T&L и возможность размещать вершинные буферы в видеопамяти, что позволило уже через 2-3 года кратно увеличить полигональность моделей в играх.
Сравните детализацию в Porsche Unleashed и HP2. Разница на лицо
Auburn, уже под финальным названием Intel i740, появился в начале 1998 года и должен был конкурировать с новым ATi Rage 128. На первый взгляд, это был суперсовременный и доступный GPU на момент выхода:
В i740 был встроен 2D-ускоритель с аппаратным ускорением GDI и DirectDraw, поддержкой разрешения до 1280x1024 при 16-битном цвете и поддержкой как VGA, так и NTSC/PAL для вывода изображения на телевизор.
Помимо 2D-ускорителя, в GPU был также аппаратный декодер DVD. Это уже очень серьезная заявка на успех с учетом того, что не каждый процессор в те годы мог программно декодировать MPEGII.
3D движок поддерживал все современные на тот момент возможности: Z-буфер, MSAA, затенение по методу Гуро, попиксельный туман, альфа-блендинг, альфа-тест, дизеринг, трилинейную фильтрацию. Из текстурных форматов поддерживалась палитровые, 1555, 565 и 4444 — никаких 24 и тем более 32 битных текстур.
На бумаге GPU работал на частоте в 133МГц, имел приличный филлрейт в ~55 мегапикселей, мог растеризовывать до ~350к треугольников в секунду (или около 11к треугольников на один кадр — это не так мало, как кажется. В HL ~4к треугольников на кадр к примеру).
И самое главное — никаких собственных GAPI, полный ориентир на OpenGL и Direct3D.
Всё это было выполнено на техпроцессе в 350нм и при скромной розничной цене в 120$. Звучит как что-то невероятное, однако на практике FPS в играх был не особо высокий из-за использования GART: видеокарте постоянно приходилось бороться с процессором за возможность доступа к оперативной памяти, из-за чего страдала пропускная способность как со стороны GPU, так и со стороны процессора. Добавьте к этому невысокую частоту FSB и самой SDRAM и получаем просадки растущие не только от объёма геометрии в кадре, но и количества наносимых текстур, благо i740 не поддерживал мультитекстурирование.
Очевидно что в 1998 году, большинство 3D-акселлераторов проектировались как игровые и i740 стал провалом в геймерском сегменте из-за невысокого FPS в играх. Ситуация становилась ироничной из-за того, что Intel выпустила специальную PCI-версию, для которой отдельно разработала чип-мост, перенаправляющий обращения к GART с северного моста на дополнительные чипы SGRAM распаянные на плате. PCI-версия стоила значительно дороже и нивелировала все плюсы i740, хоть и работала в играх чуть быстрее, что иронично.
Фото с сайта vgamuseum
Однако огромным плюсом были адекватные драйвера для OpenGL и Direct3D. До 1998 года, большинство видеокарт были ориентированы в первую очередь на свои собственные проприетарные графические API — у 3dfx был Glide, у S3 — Metal (не тот что у Apple), а у ATi — CIF, в то время как i740 был ориентирован на стандартные API. При этом все три API взваливали задачу написания аллокатора текстур, математической библиотеки и вершинного конвейера на программиста, что заметно увеличивало порог входа для разработки 3D-игр. У GL и D3D же это всё было готово «из коробки», благодаря чему большинство игр уже в 1999 году перешли на DirectX. Для понимания почему так произошло — окромя Nvidia, ни у одного производителя GPU в 90-х не было адекватных драйверов для OpenGL. У 3dfx был обрубок под названием MiniGL специально для Quake, у ATi драйвера были кривыми вплоть до ~2001 года, а у S3/SiS вообще всё с этим было максимально плохо, поэтому и победил DirectX.
Ещё одна причина почему победил в DirectX
Во времена DirectX 6 было два режима D3D — Immediate и Retained. Immediate больше всего похож на современные графические API, поскольку сразу оперировал программными командными буферами, и аппаратными вершинными/индексными буферами, что позволило прозрачно для игр использовать T&L и заметно поднять их производительность.
Retained же представлял из себя почти готовый графический движок с полноценным графом сцены, математической библиотекой и даже API для загрузки моделей/текстур с диска. Retained-режим очень сильно снижал порог входа в сферу, благодаря чему некоторые игры использовали именно его.
Касательно конкретных фишек у i740 всё тоже было не идеально. Во первых, как я и говорил ранее, i740 не имел поддержки мультитекстурирования, что требовало двухпроходной отрисовки уровней — сначала геометрия с текстурой, затем та же самая геометрия с лайтмапой. Больше всего это было актуально для Half-Life и Quake. Во вторых, i740 не поддерживал Stencil-буфер и соответственно стенсильные тени в реальном времен. Можно было только очень костыльно реализовать самые примитивные Shadowmap'ы без фильтрации, но выглядели они отвратительно.
Примерный уровень графики на i740 из демки. На дне каустики, дорисованные вторым проходом
И в третьих — i740 не поддерживал текстурную компрессию, которая позволила бы заметно выиграть в производительности. Дело в том, что блочные алгоритмы типа DXT позволяют хранить блок из 16 пикселей всего в 8 байтах (двух машинных словах) и отлично кэшируются, что помогло бы разгрузить шину... но имеем что имеем. В играх i740 показывал себя в целом очень даже неплохо, но уступал решениям от ATi и Nvidia, а ещё по каким-то причинам GPU не использовался в ноутбуках (скорее всего из-за отсутствия поддержки LVDS).
Результаты в играх были неплохими, но не более того. В Quake 3 i740 в AGP-версии выдавала солидные 30 FPS (а PCI-версия всего 20), в то время как в Quake 1 кадровая частота местами подлетала почти до 50 FPS. В Carmageddon II приходилось наслаждаться 20-22 FPS на обеих версиях, зато Mortal Kombat 4 шел в 50 на PCI версии и 60 на AGP. В MS Flight Simulator 98, i740 вытворял чудеса и выдавал более 60 FPS - это уже FPS уровня современного геймера.
Несмотря на все свои недостатки, i740 не отправился в помойку: несмотря на провал на розничном рынке, i740 стоил очень недорого на оптовом для OEM, что и обеспечило ему большую популярность в готовых сборках. А годом позднее, GPU был интегрирован в чипсет Intel i810, где и раскрыл свой бюджетный потенциал во всю. Его основными конкурентами стали SiS Mirage Graphics на базе SiS 6326 (обычно была слабее Intel'ов), VIA Unichrome на базе легендарного S3 Savage, и такая экзотика, как Trident CyberBLADE XP. В 2004'ом, Intel выпустила современный и относительно крутой GPU под названием GMA900 с поддержкой Direct3D9 и продвинутым шейдерным конвейером, но... об этом как-нибудь в другой раз.
❯ Заключение
Вот такой была первая видеокарта от Intel. И, судя по всему, из года в год Intel повторяет историю точь в точь: разрабатывают продвинутый GPU с поддержкой всех современных технологий, но спотыкаются об использование RAM в качестве основной памяти и кривоватые драйвера. Хотя сейчас с появлением Intel Arc ситуация кратно улучшилась. А что вы думаете о GPU от Intel? Пишите своё мнение в комментариях!
В будущем хотелось бы написать статью про что-то из Trident'ов, PowerVR, Trident'ов или ранних 3dfx, но к сожалению пока возможности купить их нет. Но там будь что будет :)
Ну а я надеюсь, что вам было интересно. Подписывайтесь на блог, чтобы не пропускать новые статьи каждую неделю! А если вам интересна тематика ремонта, моддинга и программирования для гаджетов прошлых лет — подписывайтесь на мой Telegram-канал «Клуб фанатов балдежа», куда я выкладываю бэкстейджи статей, ссылки на новые статьи и видео, а также иногда выкладываю полезные посты и щитпостю. А ролики (не всегда дублирующие статьи) можно найти на моём YouTube канале.
А если вы хотите что-нибудь подарить из железа и увидеть о нём статью — пишите мне в Telegram. Меня очень интересуют самые разные гаджеты: начиная от игровых консолей и любых связанных с геймингом устройств, телефонов, смартфонов, КПК, заканчивая ретро-компьютерами и ноутбуками. Кто знает, может героем следующейподобной статьи окажется ноутбук из 90-х? :)
После обзоров устройства не продаются, а остаются в моей коллекции. Когда-нибудь я хочу сделать музей, где к каждому устройству можно будет приложить QR и почитать мою статью. Кто знает, вдруг на следующей неделе я также подробно расскажу про девайс из вашей юности? :)
Кстати, у меня есть GameBoy Advance SP, под который я очень хочу написать игру. Однако мой экземпляр был залит водой и кофе. Может у кого-то есть донор с дохлой платой, откуда я смог бы взять контроллер питания? У меня AGS-101.
На выставке Computex компания KLEVV показала сразу несколько новых решений DDR5 — от экстремально быстрых комплектов до модулей с повышенным объёмом для мощных рабочих станций и игровых ПК.
Главной новинкой стал комплект KLEVV CRAS Vα RGB DDR5 CUDIMM. Он включает два модуля по 24 ГБ, то есть 48 ГБ суммарно, и способен работать на скорости до 10 000 МТ/с. Такое решение ориентировано на платформы Intel CUDIMM, включая серию Core Ultra 200S. Демонстрация проходила на материнской плате ASRock Z890 Taichi OCF.
Для пользователей AMD компания подготовила линейку EXPO ULL. Модель CRAS V RGB PRIME работает на скорости до 6000 МТ/с и предлагает комплект объёмом 32 ГБ с таймингами CL26. Такой акцент на низкие задержки может быть особенно интересен для игровых сборок и систем на Ryzen.
Также KLEVV представила BOLT Vα с поддержкой AMD EXPO. Эти модули работают на скоростях от 6000 до 7200 МТ/с, а объём отдельных планок достигает 32 ГБ.
Ещё одна новинка — серия LITE V RGB. Она поддерживает модули объёмом до 64 ГБ, что позволяет собрать систему с общим объёмом памяти до 256 ГБ. А для более профессиональных и ёмких конфигураций KLEVV показала 4R CUDIMM: каждый модуль вмещает 128 ГБ и работает на скорости до DDR5-8000 МТ/с.
Главный вывод: рынок DDR5 продолжает быстро развиваться. Производители уже соревнуются не только в частотах, но и в объёмах, задержках и поддержке разных платформ. Новые решения KLEVV должны выйти до конца года.
В сеть попали первые подробности о будущих мобильных процессорах Intel Core 400 на архитектуре Wildcat Lake Refresh. Хотя нынешняя линейка Intel Core 300 на Wildcat Lake появилась совсем недавно, инсайдер Jaykihn уже раскрыл характеристики следующего поколения бюджетных CPU, которое ожидается в 2027 году.
Главное изменение — увеличение количества производительных ядер. Если актуальные Wildcat Lake используют схему 2+0+4, то есть два P-ядра и четыре сверхэкономичных LP-E ядра, то Wildcat Lake Refresh должен перейти на конфигурацию 4+0+4. Это означает, что число мощных ядер вырастет вдвое, а общая конфигурация достигнет 8 ядер.
Новые процессоры, по данным утечки, получат архитектуры, знакомые по старшим Panther Lake: производительные ядра Cougar Cove и энергоэффективные Darkmont. При этом Wildcat Lake Refresh останется более доступным решением. В отличие от Panther Lake, здесь CPU и GPU будут размещены на одном кристалле, без сложной чиплетной компоновки.
Производство, как ожидается, будет идти по техпроцессу Intel 18A. Графическая часть при этом почти не изменится: процессоры сохранят два графических ядра Xe3. Новинки должны войти в семейство Intel Core 400 и появиться в сериях Core 5 и Core 7.
Самые доступные модели Core 3, вероятно, останутся на текущих шестиядерных решениях Core 300. Если утечка подтвердится, Intel постепенно переведёт Wildcat Lake из ультрабюджетного сегмента в более производительный класс ноутбуков, а дешёвые модели оставит для базовых устройств.
В сеть попали новые подробности о будущих процессорах AMD Zen 6, известных под кодовым названием Medusa. Информацией поделился инсайдер Moore’s Law Is Dead, поэтому важно понимать: пока это утечка, а не официальное заявление AMD.
Главная интрига — рекордные частоты. По данным источника, производительные ядра Zen 6 смогут работать на частоте около 6,5 ГГц из коробки, а настольные модели в режиме Boost могут достигать 6,6 ГГц и даже приближаться к 7 ГГц. Если это подтвердится, AMD сможет превзойти нынешние рекордные потребительские процессоры Intel по максимальной частоте.
Добиться такого результата компания может за счёт перехода на 2-нм техпроцесс TSMC N2X. Именно на нём, по слухам, будут производиться процессорные чиплеты нового поколения.
Не менее интересна мобильная линейка Medusa. Базовый Medusa Point может получить до 10 ядер Zen 6 и встроенную графику RDNA 4. Более мощный Medusa Halo Mini, по утечке, будет оснащён 14-ядерным CPU и графикой RDNA 5, производительность которой может приблизиться к уровню GeForce RTX 4060. А флагманский Medusa Halo может получить до 26 ядер и ещё более мощную встроенную графику.
Также AMD якобы готовит графические чиплеты Alpha Trion, которые могут использоваться в настольных видеокартах, мобильных процессорах и будущих игровых консолях Xbox. Для доступного сегмента упоминается отдельный процессор Bumblebee с 6 ядрами Zen 6 и графикой RDNA 4.
Если планы не изменятся, первые настольные Zen 6 и мобильные Medusa Point могут появиться в первой половине 2027 года, а официальный анонс может состояться на CES 2027. AMD явно делает ставку не только на CPU-производительность, но и на серьёзное усиление встроенной графики.
На свете есть не так много вещей, способных выбесить программиста. И лишь одна делает это с гарантией: оборзевшая машина, возомнившая себя умнее человека.
А значит снова пришло время карать и патчить!
Видите эти повторяющиеся записи справа? Так будет выглядеть буфер сообщений ядра (dmesg), если вам не повезло нарваться на этот баг.
Direct Rendering Manager (DRM)
Развитие современных видеокарт пошло по весьма.. сюрреалистичному пути:
производители страстно желают, чтобы выпускаемые устройства имели максимальную совместимость с модными открытыми ОС, но одновременно были закрытыми и неповторимыми, защищенными разнообразными патентами.
То что звучит как чистая шизофрения для человека с техническим образованием, будучи спущенным сверху в виде директивы, еще и подкрепленной серьезным бюджетом, породило на свет такую «хтонь» как binary blob.
Это когда основная часть управляющей устройством логики реализуется в виде специальной прошивки с защитой и обфрускацией — того самого «блоба».
Затем вокруг создается открытая часть ПО, которая линкуется с открытым ядром и/или окружением. А все это вместе и без смущения объявляется как частично беременна открытое решение.
The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards
Если кратко и цензурно, то это такая специальная дыра в ядре Linux, для максимально быстрой коммуникации между видеокартой и клиентским ПО, создаваемая в первую очередь ради видеоиг.. скажем так «медийных приложений, требующих аппаратного ускорения графики».
В угаре оптимизации «ядростроители» дошли до использования 3D-ускорения (GPU) даже для отрисовки терминала текстовой консоли (тот самый KMS):
И теперь мы все имеем клевый терминал в разрешении 1920×1280 со сглаживанием шрифтов, на котором что-то разобрать возможно лишь с лупой прищурившись.
Угар портирования
Под натиском волн малолетних специалистов, желающих «гонять игоры» на серверной ОС, не выдержали даже разработчики FreeBSD:
подсистема DRM и KMS, вместе с проприетарными блобами была перенесена из Linux и теперь вовсю используется в FreeBSD.
По-умолчанию, да.
Кстати с тех лет и до сих пор разработка DRM синхронизируется с апстримом (а это внезапно отдельный проект) и ядром Linux, заезжая в сборки FreeBSD вместе со всеми свежими багами в виде срезов исходников. Основная разработка при этом едет дальше.
Нетрудно догадаться, что отправлять багрепорты в проект drm-kmod, курируемый FreeBSD или апстрим ядра Linux при таком подходе равнозначно отправке в «Спортлото».
Заодно во FreeBSD были фактически похоронены альтернативные варианты:
старый текстовый TTY и Xorg-драйвер для видеокарт Intel пока еще существуют и собираются в виде пакетов, но вот их настройку и главное — все сопутствующие сбои в клиентском ПО вы теперь вынуждены отлавливать и исправлять самостоятельно.
«Интерес сообщества» к таким технологиям оказался утрачен.
В качестве вишенки на этом интересном торте из говна, добавлю что всенародно любимый браузер Google Chrome плохо работает без модуля KMS, поэтому заводить весь этот цирк с DRM и KMS приходится даже на откровенно винтажных машинах — ради работающего браузера.
И других вариантов уже фактически нет.
Как-то так выглядит процесс попадания обновлений DRM в FreeBSD. FreeBSD — крайний справа, увы.
Оборзевшая техника
Вся эта технологическая «многоножка» из разработчиков Intel с блобами, апстрима ядра Linux с любовью к тотальным переделкам на Rust, на практике приводит к тому, что в бедную FreeBSD постоянно попадают ломающие обновления, отследить и исправить которые «в моменте» не получается.
«Думали что работает» — говорят в таких случаях разработчики FreeBSD и советуют обновиться до -CURRENT версии.
Что для обычных людей и рабочего окружения на машине равносильно старому японскому ритуалу сеппуку, поскольку упадет и сломается вообще все.
В какой-то момент обновление пакета drm-kmod, содержащего тот самый порт подсистемы DRM из ядра Linux принесло мне такое:
drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080
Ну принесло и принесло, ошибок много разных, исправляются далеко не все, дело это небыстрое и так далее.
Но только эта забивала собой весь буфер сообщений ядра!
Сообщений генерировалось настолько много, что dmesg — команда для отображения этого самого буфера, показывала только одну эту бесконечно повторяющуюся ошибку, как на скриншоте в шапке статьи.
Но самое веселое, что баг оказался с рогами и копытами совсем не специфичным и само сообщение означает буквально.. ничего.
Просто «что-то сломалось», в переводе с языка Intel.
Ну что, вы все еще любите проприетарные драйвера от уважаемых производителей?
Беглый поиск в репозитории, в котором ведется разработка подсистемы DRM (напоминаю, она ведется отдельно от ядра Linux) показал, что сообщений с этой ошибкой навалом:
88 репортов, только в этом довольно новом репозитории.
Положение дел
В итоге есть некий баг, с гнездом в районе прошивки видекарты Intel, который (судя по репортам) зверствует проявляет себя самым феерическим образом:
от спама сообщениями до мигания экрана и полного зависания системы.
Исправить своими силами этот баг нельзя, все «workaround» в сети по накалу дичи в рекомендациях напоминают известное шоу «Битва Экстрасенсов»:
нарисуйте ночью в поле пентаграмму из соли, разложите по углам загрузочные диски FreeBSD с 5й по 10ю и громко читайте Changelog задом наперед.
Первая заключается в том, что в свежих прошивках баг вроде бы исправили на стороне Intel, но чтобы эту прошивку поставить — нужна сборка модуля DRM для FreeBSD 15, которая еще не была выпущена на момент написания статьи:
Еще стоит рассказать, что прямо сейчас идет серьезная работа по перепиливанию DRM как в его основном проекте так и на стороне команды FreeBSD (в -CURRENT), поэтому даже пытаться бекпортировать текущую версию drm-kmod в 14.х ветку не стоит.
Также (к сожалению) не стоит рассматривать переезд на 15ю версию как гарантированное решение, поскольку есть уже открытые багрепорты и оттуда:
Хотя тут явно использовалась 6.1 версия.
Вторая хорошая новость заключается в том, что на двух моих ноутбуках, где проявляется данный баг все работает без критических сбоев — без мигания и зависаний системы. А само сообщение до недавних пор глушилось настройкой:
compat.linuxkpi.i915_disable_power_well="0"
Так что конкретно в моем случае, проблема заключается лишь в бесконечном затирании буфера сообщений ядра этой дурацкой и бессмысленной ошибкой:
drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080
Которую мы и будем сейчас цинично глушить.
Аморальный патч
Разумеется так делать нельзя:
глушить сообщения об ошибках в ваших реальных проектах не стоит.
Хотя если в вашем проекте возникает ситуация, когда сообщение об ошибке генерируется по сотне раз за секунду — ну наверное вопрос уже к вам как к разработчику, допустившему такую дичь.
К счастью FreeBSD проект не мой, прямого доступа к разработчикам нет, а сам процесс разработки подсистемы DRM сильно напоминает известный фильм «Human Centipede».
Где (а главное — зачем) искать концы в такой ситуации не очень понятно, для примера багрепорты по ошибкам DRM в трекере ядра Linux сразу просят перенаправлять в отдельный проект, не разбираясь:
Так что было решено применить военную хитрость просто заглушить сообщение об ошибке в исходниках, пересобрав DRM из портов.
Так выглядит конечный результат после патча:
Как видите буфер ядра не забит этими дурацкими сообщениями.
Поскольку новая 15я по счету версия FreeBSD еще официально не вышла на момент написания статьи, я все еще использую 14.3, где максимально доступная версия DRM для этой ветки — 6.1.
Ее мы и будем жестоко патчить.
В портах она находится в этом каталоге:
/usr/ports/graphics/drm-61-kmod
Поиск в исходном коде по тексту сообщения об ошибке показал, что генерируется она всего в одном месте, в файле i915_irq.c:
if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), fault_errors); ..
Все что нужно сделать — закомментировать этот блок, начиная с условия.
И все, больше вы это проклятое сообщение не увидите, ура.
Для уменьшения работы мозгом у дорогих читателей, подготовил на этот раз готовый патч, который достаточно положить в специальный каталог и он автоматически применится при сборке drm-kmod.
Надо создать файл patch-i915_irq.c в каталоге /usr/ports/graphics/drm-61-kmod/files, затем вставить туда вот такое содержимое:
*** drivers/gpu/drm/i915/i915_irq.c.orig Tue Nov 18 17:17:39 2025 --- drivers/gpu/drm/i915/i915_irq.c Tue Nov 18 17:17:52 2025 *************** *** 2571,2585 ****
if (iir & gen8_de_pipe_underrun_mask(dev_priv)) intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv); ! if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), ! fault_errors); }
if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) && master_ctl & GEN8_DE_PCH_IRQ) { /*
Дальше просто перезапускаем сборку:
make clean make
Проверяем что изменения в файле i915_irq.cприменились и запускаем установку собранного пакета:
make reinstall
После чего перезагружаем систему.
Если все прошло удачно — дурацкое сообщение вас больше беспокоить не будет, если нет — компьютер взорвется система скорее всего зависнет при запуске, либо вас будет ожидать черный экран.
Но главное это разумеется хорошее настроение и поставленная на место машина, вернувшаяся к своей основной задаче служить людям.
P.S.
Ошибка действительно дурацкая, еще и наведенная — если дойдет до серьезных сбоев вроде мигания экрана (screen flickering), вы увидите дополнительные сообщения в логах, по которым можно продолжать искать реальную проблему.
Так что вопрос удаления этого сообщения чисто косметический и частично — лишней нагрузки, поскольку генерация сотен таких сообщений в секунду разумеется нагружала систему.
Во времена XP, я на её присутствие забивал, ну есть и есть.
Во времена 7-ки меня начал бесить драйвер в пару сотен метров, нахер не нужный, поэтому я написал батник, ставящий null драйвер (что бы диспетчере вопросы не висели и сон работал):
@chcp 1251>nul&&more +1 "%~f0">null_drv.inf &pnputil.exe -i -a "%cd%\null_drv.inf" &del "%cd%\null_drv.inf"
