Сегодняшняя статья будет посвящена сразу двум нашим любимым темам: компьютерной томографии (КТ) и отечественному процессору Эльбрус. Мы расскажем, чем отличается рентгенограмма от результатов КТ и объясним, зачем такой большой и серьезной машине, как томограф, был бы кстати специализированный вычислитель. Несмотря на то, что томографы используются уже почти 50 лет (создание первого томографа было анонсировано в 1972 году [1]), это не означает, что все проблемы KT сегодня решены. Наоборот, существует острая потребность в новых томографических алгоритмах, которые были бы быстрее и точнее используемых, позволили бы уменьшить лучевую нагрузку на объект, что, в свою очередь, существенно расширило бы и сферу применения метода КТ. Понимая все это, мы создали такое программное обеспечение Smart Tomo Engine. О нем речь пойдет ниже. Рассказав ранее о борьбе с ортотропными артефактами и об оценке эффекта чаши, в данной статье мы опишем несколько тестов, проведенных с использованием синтетических и собранных на отечественном томографе реальных томографических датасетах и покажем работу нашей программы на процессоре Эльбрус нового поколения (видео прилагается ниже). Результат работы программы приоткроет внутренний мир майского жука, причем значение слова внутренний здесь следует понимать буквально.

Рентгенография широко используемый метод неинвазивной диагностики, основанный на формировании изображения объекта с помощью рентгеновского излучения. Для этого исследуемый объект помещается между источником рентгеновского излучения и регистратором (рис. 1 слева). В качестве регистратора может выступить рентгеночувствительная пленка или позиционно-чувствительный детектор. Изображение формируется прошедшим через объект и ослабленным при своем прохождении излучением. Разные материалы ослабляют рентгеновское излучение по-разному, что обеспечивает контраст на изображении. Регистрируя прошедшее через объект рентгеновское излучение, можно судить о локальном составе исследуемого объекта. Пример рентгенограммы грудной клетки показан на рис. 1 справа. Здесь светлые области характеризуют участки большего поглощения. Рассматривая ребра (светлые изогнутые пластинки), ограничивающие грудную клетку (темная полость с просматриваемыми светлыми участками бронхиального дерева), в верхней части грудины (центральный светлый столб) с правой стороны мы видим небольшое светлое утолщение.

Рис. 1. Рентгенография: принципиальная схема (слева); результат рентгеновского исследования рентгенограмма (справа). Источник.

Рентгенография не позволяет понять, на какой глубине находится проблемная часть прямо на грудине, перед ней или за ней. По одной проекции трудно не только проанализировать тонкую пространственную структуру проблемной части, но и определить ее общую форму. На рис. 2 данный факт и проиллюстрирован.

Рис.2. Источник.

Уточнить форму и внутреннее строение поможет метод КТ. Также как и в рентгенографии, для сбора данных КТ объект помещается между источником рентгеновского излучения и детектором, но регистрируется уже набор рентгенограмм под разными углами. Углы поворота обычно равномерно распределены в некотором интервале. Принципиальная схема измерения показана на рис. 3.

Рис. 3. Принципиальная схема томографической съемки (источник).

Сбор изображений под разными углами проводится на специальном приборе томографе. Поскольку томографироваться могут самые разные объекты живой и неживой природы, а исследования проводятся и на микро-, и макро- уровнях, то разновидностей томографов огромное число. Они отличаются схемами сканирования (послойно-круговая, спиральная и т.д.), используемыми типами источников излучения, схемами формирования зондирующего пучка (конусная, параллельная, микрофокусная). В самых общих чертах схему томографа можно представить так: источник излучения, держатель объекта исследования и детектор. Подвижной частью, позволяющей контролируемо менять ракурс съемки, может быть любая из трех частей. Современный томограф также немыслим без компьютера, который не только управляет схемой сбора рентгенограмм, но производит обработку собранных данных с помощью специализированного ПО.

Для исследования объектов разной природы могут использоваться принципиально отличающиеся друг от друга технические решения. Так, при медицинских исследованиях гентри (подвижное устройство, содержащее систему детекторов и рентгеновских излучателей) (Рис. 4) вращается вокруг неподвижного пациента. Пространственное разрешение в таких томографах достигает 0.2-0.5 мм. Результаты КТ сохраняются в формате DICOM медицинском отраслевом стандарте, разработанном для создания, хранения, передачи цифровых медицинских изображений и сопутствующих документов обследованного пациента.

Рис. 4. Схема медицинского томографа (источник).

Для научных исследований in vitro, проводимых в лабораторных условиях, применяется другая экспериментальная схема источник и детектор неподвижны, а набор рентгенограмм получают, вращая образец. Во ФНИЦ Кристаллография и фотоника РАН (ФНИЦ КФ РАН) в лаборатории рефлектометрии и малоуглового рассеяния был сконструирован и функционирует целый комплекс лабораторных рентгеновских микротомографов. Изображение одного из созданных приборов представлено на рис. 5. В нем образец размещается на гониометре, ось которого перпендикулярна направлению зондирования. Прибор оборудован двумерным детектором. Размер пикселя 9 мкм, поле зрения детектора 24 на 36 мм. В данном приборе реализована возможность использования для зондирования как полихроматического, так и монохроматического излучения. Это позволяет не только повышать качество реконструируемых изображений, но и получать дополнительную информацию об элементном составе изучаемых объектов. Разработка собственных томографов позволяет получить доступ к экспериментальным данным (рентгенограммам) и параметрам работы всех узлов томографа, а, значит, позволяет оптимизировать протоколы измерений в зависимости от поставленных задач.

Рис. 5. Фотография лабораторного микротомографа ФНИЦ КФ РАН.

После регистрации рентгенограмм под разными углами, т.е. сбора полного набора проекций, начинается их обработка. Финальная цель обработки восстановление внутренней морфологической структуры объекта. Поскольку контраст на регистрируемом изображении формируется за счет способности разных материалов по-разному ослаблять рентгеновское излучение, то результатом реконструкции является пространственное распределение коэффициентов ослабления зондирующего излучения. На это распределение и опирается описание морфологической структуры томографируемых объектов.

Если зондирование проводится с использованием параллельного пучка, то задачу трехмерной реконструкции можно решить, восстановив серию двумерных сечений объекта. Для реконструкции одного сечения нет необходимости использовать полный набор проекций. Требуется лишь одна строка фиксированного номера от каждой угловой проекции. Все эти строки соответствуют одному горизонтальному сечению восстанавливаемого 3D распределения, которому можно приписать тот же номер. На рис. 6 слева представлено изображение, собранное из таких строк. Горизонтальная ось отвечает за номер столбца детектора, вертикальная за номер углового поворота. Справа на рис. 6 приведен результат реконструкции сечения.

Рис 6. Синограмма грудной клетки (слева); результат КТ сечение 3D изображения (справа).

Если для томографического зондирования используется монохроматическое рентгеновское излучение, то, опираясь на закон Бугера-Ламберта-Бера, задачу реконструкции можно свести к задаче обращения преобразования Радона. Преобразование Радона это интегральное преобразование, которое связывает значения функции со значениями ее интегралов по всевозможным прямым. Процедура обращения это восстановление неизвестной функции по известным значениям ее интегралов по прямым. Подынтегральная функция, которую и надо восстановить это распределение линейного коэффициента ослабления монохроматического рентгеновского излучения в объеме образца. Свойство обратимости преобразования Радона гарантирует точное восстановление неизвестной частотно-ограниченной функции при наличии достаточного числа интегралов по регулярно расположенным прямым. Это свойство использует алгоритм свертки и обратной проекции (Filtered Back Projection, FBP), реализованный в большинстве современных серийных томографов. Он состоит из двух шагов. Первый шаг линейная фильтрация зарегистрированных изображений. Второй шаг обратное проецирование, т.е. равномерное размазывание каждой полученной на предыдущем шаге одномерной функции по соответствующему направлению на все двумерное изображение с последующей суммацией. Результат работы алгоритма восстановленное пространственное распределение линейного коэффициента ослабления рентгеновского излучения заданной энергии. Если зондирование ведется не параллельным, а конусным пучком, то послойную реконструкцию организовать не удается, и приходится использовать более сложные алгоритмы. Об алгоритмах трехмерной реконструкции, например об алгоритме Фельдкампа, мы напишем как-нибудь в следующий раз. А теперь перейдем, наконец, к описанию нашего ПО.

Smart Tomo Engine

Сердцем Smart Tomo Engine служит библиотека томографической реконструкции, предоставляющая через API следующие функции: чтение томографических изображений (проекций); собственно томографическую реконструкцию (предлагается на выбор три алгоритма) и сохранение результатов (предлагаемые форматы: DICOM, PNG). Программный продукт дополнительно включает в себя графический интерфейс пользователя, обеспечивающий двухмерную визуализацию томографических изображений и результатов реконструкции. Основное назначение программного продукта выполнение реконструкции трехмерного цифрового изображения объекта по набору его трансмиссионных томографических изображений в рентгеновском диапазоне.

Для послойной двумерной реконструкции реализованы следующие алгоритмы:

• FBP Filtered Back Projection. Классический метод томографической реконструкции, комбинирующий обратное проецирование и линейную фильтрацию. Вычислительная сложность O(n³). Подробнее о методе можно почитать в [2]).
• DFR Direct Fourier Reconstruction. Алгоритм работает в частотной области и использует быстрое преобразование Фурье для фильтрации и обратного проецирования [3]. Вычислительная сложность O(n² log n) операций умножений.
• HFBP Hough FBP. Алгоритм реконструкции, который разработали наши ученые. Для обратного проецирования используется алгоритм Брейди быстрого вычисления преобразования Хафа, а для ускорения линейной фильтрации применяется метод Дериша [4,5]. Вычислительная сложность по сравнению с DFR снижена до O(n²) операций умножения (при O(n² log n) операций сложения).

Тестирование на Эльбрус

Мы протестировали наше ПО на отечественной платформе. Тестирование проводилось на машинах Эльбрус-401, Эльбрус-804 и Эльбрус-801СВ. Эльбрус-401 это рабочая станция с процессором Эльбрус-4С, Эльбрус-804 сервер с 4 процессорами Эльбрус-8С. (Мы уже тестировали на них наше ПО, разработанное для решения других задач, и почитать про это можно, например, тут.) Эльбрус-801СВ это новейшая разработка МЦСТ: рабочая станция с процессором Эльбрус-8СВ. Про принципиальные отличия Эльбрусов разных поколений нам рассказали коллеги из МЦСТ: Эльбрус-4С первый процессор, массово поставленный на рынок. Имеет 4 ядра с частотой 750800 МГЦ, 3 канала памяти DDR3-1600. Эльбрус-8С 8 ядер, частота 1.21.3 ГГц, 4 канала памяти DDR3-1600, и при этом в каждом ядре в 1.5 раза больше исполнительных устройств (ALU) для вычислений с плавающей запятой. Эльбрус-8СВ дальнейшее улучшение: 8 ядер с частотой 1.5 ГГц, память DDR4-2400 и ещё в 2 раза больше ALU. Эльбрус-8СВ лучше работает с невыровненными данными, и в нём масса других небольших улучшений по сравнению с Эльбрус-8С.

Характеристики процессоров представлены в таблице 1.

Таблица 1. Технические характеристик использованных процессоров.

Про оптимизацию на платформе Эльбрус мы уже писали тут и тут, поэтому не будем повторяться. Здесь мы не делали ничего сверхъестественного:

• использовали оптимизированную библиотеку EML (геометрические преобразования изображения (напр., аффинное преобразование), арифметические операции и т.д.);
• использовали интринсики там, где EML не смогла нам помочь; однако на Эльбрус-8СВ SIMD стал 128-битным, и мы не успели полностью на него перейти, поэтому интринсики все еще работали с 64-битными векторами.

Для тестирования Smart Tomo Engine мы собрали два датасета: с синтетическими и реальными данными. Синтетический датасет Шепп-Логан 3D был получен методом математического моделирования. Проекции рассчитаны послойно от трехмерного фантома Шеппа-Логана с использованием веерной схемы. Срез представлен на рис. 8 слева. Размер изображения фантома 511х511х511. Проекции рассчитаны для 420 углов, равномерно распределенных от 0.5 до 210 градусов. В эксперименте на вход Smart Tomo Engine подавалось 511 синограмм (изображение одной из них приведено на рис. 7 справа) размером 511х420. Выход 511 реконструированных слоев, размер каждого слоя 511х511. Размер фантома примерно соответствует изображениям, получаемым на современных стоматологических томографах: максимальный размер зоны сканирования челюсти обычно составляет 16 см, заявляемое производителями пространственное разрешение 0.3-0.4 мм. В таком случае размер регистрируемой проекции составит примерно 500х500 пикселей.

Рис. 7. Слева срез трехмерного фантома Шеппа-Логана, справа синограмма центрального слоя.

Реальные томографические данные (датасет "Майский жук") были собраны на микротомографе ФНИЦ КФ РАН, предназначенном для проведения научных исследований. Размер пикселя использованного детектора составлял 9 микрон. Экспериментальный образец высушенный майский жук. Было снято 400 проекций в параллельной схеме. Образец, закрепленный на держателе, поворачивался на углы в диапазоне от 0.5 до 200 градусов с шагом 0.5 градусов. Время измерения одной проекции составило 5 секунд. Размер измеренной проекции 1261х1175. Вход для Smart Tomo Engine 1261 синограмма размером 1175х400, выход 1261 восстановленный слой размера 1175х1175.

А теперь самое интересное результаты замеров и выводы

На этих датасетах мы провели замеры скорости выполнения реализованных нами алгоритмов реконструкции: FBP, DFR и HFBP. Время работы алгоритмов приведено в таблице 2. Замеры проводились на 5 машинах: Эльбрусе-401, Эльбрусе-804, Эльбрусе-801СВ, AMD Ryzen 7 2700 и AMD Ryzen Threadripper 3970X. Для каждой машины в таблице указано число процессоров, число физических ядер и максимальное число одновременно выполняемых потоков (указано в скобках). Замеры скорости реконструкции проводились в двух режимах: однопоточном (1П) и многопоточном (МП), реализованном с помощью библиотеки tbb версии 2017 update 7.

Таблица 2. Замеры времени работы программы, сек.

Анализируя полученные результаты, прежде всего отметим, что в многопоточном режиме 4-процессорный сервер Эльбрус-804 затратил на реконструкцию 511 слоев фантома алгоритмом HFBP 19 секунд, то есть каждый слой был восстановлен за 0.037 секунды, а послойная частота составила 26.8 слоев в секунду (26.8 ips). Чтобы понять, высокая это частота или низкая, приведем следующую оценку. За секунду гентри 16-срезового кардиологического томографа совершает чуть меньше двух оборотов, регистрируя порядка 30 синограмм. Мы восстанавливаем 26.8 слоя в секунду, т.е. проводим реконструкцию практически в режиме реального времени. Таким образом, проведение реконструкции с использованием российской платформы удовлетворяет требованиям по скорости, предъявляемым в кардиологии, где основным реперным параметром является период сокращения сердца, который в среднем составляет одну секунду.

Реконструкция в реальном времени требуется также для реализации нового протокола сканирования, предложенного недавно нашими учеными контролируемой реконструкции [6]. Использование этого протокола уменьшает лучевую нагрузку за счет того, что сбор рентгенограмм прерывается сразу, как только их набор оказывается достаточным для восстановления.

Для научных исследований таких жестких ограничений по времени нет, но выше требования к пространственному разрешению. Поэтому размеры восстанавливаемых сечений больше. При работе с датасетом, полученным с лабораторного микротомографа, на реконструкцию 1261 слоя потребовалось 189 секунды в многопоточном режиме (6.7 ips). Измерение входных данных на лабораторном томографе заняло 2000 секунд, а 3 с небольшим минуты, которые потребовались на реконструкцию всех слоев при использовании Smart Tomo Engine на Эльбрусе-804, соответствуют 10% этого времени. Ещё быстрее будет работать 4-процессорный сервер с процессором Эльбрус-8СВ, который в МЦСТ уже разработали и скоро планируют довести до готовности к серийному производству.

В полученных результатах интересны и сами по себе соотношения производительностей разных платформ на каждом из алгоритмов, с учётом тактовой частоты ядер. На FBP отставание Эльбрусов умеренное, и при нормировании относительно тактовой частоты получаются близкие результаты. Но на алгоритмах DFR и HFBP отставание всех Эльбрусов от платформы х86 значительно больше. Почему? Ответ кроется в недостаточной оптимизации нашего ПО под платформу Эльбрус, все же на x86_64 мы потратили 5 лет, а под Эльбрус, особенно под 8СВ, большую часть программ и алгоритмов мы еще вовсе не оптимизировали.

В ближайшее время мы планируем ускорения в трех направлениях. Первое, что мы сделаем, это оптимизируем наши вычисления на интринсиках. Сейчас наши вычисления сделаны для 64-битного SIMD, а у Эльбрус-8СВ SIMD стал 128-битным. Второе ускорение будет сделано командой МЦСТ. Уже сейчас ведутся разработки для поддержки двумерного и одномерного дискретного преобразования Фурье для входного вектора, размер которого не равен степени двойки. И так как пока его нет, мы пользовались библиотекой ffts, с некоторой доработкой как под Эльбрус, так и под х86.

Для оценки возможного ускорения нашей программы мы сделали замеры времени выполнения дискретного преобразования Фурье на процессоре Эльбрус-8СВ для входной комплексной матрицы размером 512 на 512. Неоптимизированная на Эльбрус библиотека ffts выполнила эту операцию за 27 миллисекунд, а eml справилась всего за 5.5. Мы ускорили, как могли, ffts с помощью вызовов EML в 2 раза, и в таблице 2 замеры проведены уже с учётом этой оптимизации. Таким образом, если оптимизацию проводить с той тщательностью, с которой сделана библиотека eml, то алгоритм DFR на Эльбрусе все еще может быть ускорен почти в 2,5 раза.

Третье, но не менее важное ускорение относится к алгоритму HFBP, который основан на применении преобразования Хафа. Данное преобразование также пока еще не представлено в библиотеке eml, а наша версия оптимизирована только с помощью векторных операций. И, так как данный алгоритм вычислительно эффективнее, чем DFR, наши теоретические выводы и оптимизированная под платформу x86_64 версия это показывают, то данный алгоритм тоже может быть ускорен еще в несколько раз. О результатах этих оптимизаций мы обязательно расскажем в следующий раз.

А вот и обещанное видео с работой программы на Эльбрус-8СВ.

Вот такой внутренний мир майского жука у нас получился.

Заключение

В статье мы представили вам нашу новую разработку программное обеспечение для томографической реконструкции Smart Tomo Engine, которое:

• включает в себя инновационный алгоритм HFBP, стабильно обгоняющий по производительности лидера прошлых лет DFR;
• поддерживает операционные системы: ОС Эльбрус, MS Windows, macOS, различные дистрибутивы Linux;
• поддерживает процессорные архитектуры: Эльбрус, x86, x86_64;
• является полностью отечественной разработкой;
• в составе программно-аппаратного комплекса на платформе Эльбрус подходит для медицинских и промышленных сканеров всех поколений, для новейших нано-томографов (приборов, которые реконструируют объекты с субмикронным разрешением), а также синхротронных центров.

Ну а главный результат этой статьи заключается в том, что комбинации отечественного процессора Эльбрус и Smart Tomo Engine достаточно для томографии в реальном времени, даже без дополнительных ускорений, работа над которыми уже ведется!

P.S. А еще мы не смогли удержаться и замерили производительность UNetа на Эльбрусе. UNet популярная нейросетевая архитектура для решения задач сегментации. Изначально Unet была разработана для решения задачи сегментации в медицине, а по обработанным этим нейросетевым подходом томографическим снимкам теперь определяют патологии и новообразования. Вычислительно тяжелые части нейронных сетей у нас реализованы на EML, а EML оптимизировано под разные поколения Эльбрусов, поэтому на таком замере можно лучше оценить реальную производительность разных процессоров. Замеры выполнены для одного ядра, без распараллеливания, чтобы не оглядываться на число ядер.

Обратите внимание на последние две цифры. Круто?.. А наши исследования продолжаются...

Введение

Mass Effect популярная франшиза научно-популярных RPG. Первая часть сначала была выпущена BioWare в конце 2007 года эксклюзивно для Xbox 360 в рамках соглашения с Microsoft. Спустя несколько месяцев, в середине 2008 года, игра получила порт на PC, разработанный Demiurge Studios. Порт был достойным и не имел заметных недостатков, пока в 2011 году AMD не выпустила свои новые процессоры на архитектуре Bulldozer. При запуске игры на PC с современными процессорами AMD в двух локациях игры (Новерия и Илос) возникают серьёзные графические артефакты:


Да, выглядит некрасиво.

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

Почему эта проблема так интересна? Баги, возникающие только на оборудовании отдельных производителей, встречаются довольно часто, и в играх они встречаются уже много десятилетий. Однако, по моей информации, это единственный случай, когда проблема с графикой вызвана процессором, а не графической картой. В большинстве случаев проблемы возникают у продуктов определённого производителя GPU и никак не касаются CPU, однако в данном случае всё совсем наоборот. Поэтому эта ошибка уникальна, а значит, её стоит исследовать.

Почитав онлайн-обсуждения, я пришёл к выводу, что проблема, похоже, касается чипов AMD FX и Ryzen. В отличие от более старых процессоров AMD, в этих чипах нет набора команд 3DNow!. Возможно, ошибка никак с этим не связана, но в целом у сообщества геймеров сложился консенсус о том, что это причина бага и что обнаружив процессор AMD, игра пытается использовать эти команды. Учитывая то, что случаи возникновения этого бага на процессорах Intel неизвестны, и что команды 3DNow! использовала только AMD, неудивительно, что сообщество посчитала причиной этот набор команд.

Но в них ли проблема, или ошибку вызывает нечто совершенно другое? Давайте выясним!

Часть 1 Исследования

Прелюдия

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

Так как теперь у нас была тестовая среда, первой, разумеется, мы протестировали теорию cpuid если люди правы, предполагая, что следует винить команды 3DNow!, то в коде игры должно быть место, проверяющее их наличие, или хотя бы определяющее изготовителя CPU. Однако в таких рассуждений есть ошибка; если бы игра действительно пыталась использовать команды 3DNow! на любом чипе AMD без проверки возможности их поддержки, то она, скорее всего, вылетела бы при попытке выполнения недопустимой команды. Более того, краткое исследование кода игры показывает, что она не проверяет возможности CPU. Следовательно, что бы ни было причиной ошибки, не похоже, что она вызвана неправильным определением функцональности процессора, потому что игре она вообще не интересна.

Когда случай начал казаться не подлежащим отладке, Рафаэль сообщил мне о своём открытии отключение PSGP (Processor Specific Graphics Pipeline) устраняет проблему и все персонажи освещаются правильно! PSGP не самое подробно задокументированное понятие; если вкратце, то это legacy-функция (касающаяся только старых версий DirectX), позволяющая Direct3D выполнять оптимизации под конкретные процессоры:

В предыдущих версиях DirectX существовал путь выполнения кода под названием PSGP, позволявший производить обработку вершин. Приложения должны были учитывать наличие этого пути и поддерживать путь для обработки вершин ядрами процессора и графической карты.

При таком подходе логично, что отключение PSGP устраняет артефакты на AMD путь, выбиравшийся современными процессорами AMD был каким-то образом испорчен. Как его отключить? На ум приходят два способа:

• Можно передать функции IDirect3D9::CreateDevice флаг D3DCREATE_DISABLE_PSGP_THREADING. Он описывается следующим образом:
  
  

  Ограничивает вычисления только основным потоком приложения. Если флаг не установлен, то среда выполнения может выполнять программную обработку вершин и другие вычисления в рабочем потоке (worker thread), чтобы повысить производительность в многопроцессорных системах.

  
  К сожалению, установка этого флага не решает проблему. Похоже, что несмотря на наличие в названии флага букв PSGP, это не то, что нам нужно.
• DirectX задаёт два элемента регистра для отключения PSGP в D3D и для отключения PSGP только для D3DX DisablePSGP и DisableD3DXPSGP. Эти флаги можно устанавливать для всей системы или только для процесса. Подробности о его установке для конкретного процесса см. в руководстве Рафаэля Риверы по включению флагов Direct3D для отдельных приложений.

Похоже, что DisableD3DXPSGP способен решить эту проблему. Следовательно, если вы не любите скачивать сторонние исправления/модификации или хотите устранить проблему, не внося никаких изменений в игру, то это вполне рабочий способ. Если вы установите этот флаг только для Mass Effect, а не для всей системы, то всё будет в порядке!

PIX

Как обычно, при возникновении проблем с графикой их, скорее всего, поможет диагностировать PIX. Мы выполнили захват схожих сцен на оборудовании Intel и AMD, а затем сравнили результаты. Сразу же бросилось в глаза одно различие в отличие от моих предыдущих проектов, где захваты не записывали в себя баг и один и тот же захват мог выглядеть на разных PC по-разному (что указывает на баг драйвера или d3d9.dll), эти захваты записывали в себя баг! Другими словами, если открыть сделанный на железе AMD захват на PC с процессором Intel, то баг будет отображаться.

Захват с AMD на Intel выглядит точно так же, как выглядел на оборудовании, где был сделан:


О чём это нам говорит?

• Так как PIX не делает скриншоты, а захватывает последовательности команд D3D и выполняет их в оборудовании, мы видим, что при выполнении на компьютере с Intel команд, захваченных в системе с AMD получается тот же баг.
• Это определённо даёт нам понять, что разница вызвана не отличиями в том, как выполняются команды (а именно так и получаются специфичные для конкретных GPU баги), а в том, какие команды выполняются.

Другими словами, это почти точно не баг драйвера. Похоже, что входящие данные, подготавливаемые для GPU, каким-то образом искажаются ¹. Это и в самом деле очень редкий случай!

На этом этапе для нахождения бага необходимо обнаружить все расхождения между захватами. Это скучная работа, но иного пути нет.

После долгого изучения захваченных данных моё внимание привлёк вызов отрисовки целого тела персонажа:


В захвате Intel этот вызов выводит бОльшую часть тела персонажа вместе с освещением и текстурами. В захвате AMD он выводит сплошную чёрную модель. Похоже, мы взяли нужный след.

Первым очевидным кандидатом на проверку будут соответствующие текстуры, но с ними, похоже, всё в порядке и в обоих захватах они одинаковы. Однако странно выглядят некоторые константы пиксельных шейдеров. В них не только содержатся NaN (Not a Number), но они также есть только в захвате AMD:


1.#QO обозначает NaN

Выглядит многообещающе часто бывает, что значения NaN вызывают странные графические артефакты. Довольно забавно, что в версии Mass Effect 2 для PlayStation 3 была очень похожая проблема в эмуляторе RPCS3, тоже связанная с NaN!

Однако не стоит пока слишком радоваться это могут быть значения, оставшиеся от предыдущих вызовов и не используемые в текущем. К счастью, в нашем случае чётко видно, что эти NaN передаются в D3D для этой конкретной отрисовки

49652IDirect3DDevice9::SetVertexShaderConstantF(230, 0x3017FC90, 4)49653IDirect3DDevice9::SetVertexShaderConstantF(234, 0x3017FCD0, 3)49654IDirect3DDevice9::SetPixelShaderConstantF(10, 0x3017F9D4, 1) // Submits constant c1049655IDirect3DDevice9::SetPixelShaderConstantF(11, 0x3017F9C4, 1) // Submits constant c1149656IDirect3DDevice9::SetRenderState(D3DRS_FILLMODE, D3DFILL_SOLID)49657IDirect3DDevice9::SetRenderState(D3DRS_CULLMODE, D3DCULL_CW)49658IDirect3DDevice9::SetRenderState(D3DRS_DEPTHBIAS, 0.000f)49659IDirect3DDevice9::SetRenderState(D3DRS_SLOPESCALEDEPTHBIAS, 0.000f)49660IDirect3DDevice9::TestCooperativeLevel()49661IDirect3DDevice9::SetIndices(0x296A5770)49662IDirect3DDevice9::DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 2225, 0, 3484) // Draws the character model

и используемый в этой отрисовке пиксельный шейдер ссылается на обе константы:

// Registers:////   Name                     Reg   Size//   ------------------------ ----- ----//   UpperSkyColor            c10      1//   LowerSkyColor            c11      1

Похоже, обе константы берутся напрямую из Unreal Engine и, судя по их названию, они могут влиять на освещение. Бинго!

Тест в игре подтверждает нашу теорию на машине с Intel вектор из четырёх значений NaN никогда не передаётся как константы пиксельного шейдера; однако на машине с AMD значения NaN начинают появляться сразу, как игрок входит в место, где ломается освещение!

Значит ли это, что работа сделана? Далеко нет, потому что обнаружение сломанных констант только половина успеха. По-прежнему остаётся вопрос откуда они берутся и можно ли их заменить? Во внутриигровом тесте замена значений NaN частично устранила проблему уродливые чёрные пятна пропали, но персонажи всё равно выглядят слишком тёмными:


Почти правильно но не совсем.

Учитывая то, насколько важными эти значения освещения могут быть для сцены, мы не можем остановиться на таком решении. Однако мы знаем, что на верном пути!

Увы, любые попытки отследить источники этих констант указывали на нечто, напоминающее поток рендера, а не истинное место передачи. Хоть отладка этого и возможна, очевидно, что нам нужно попробовать новый подход, прежде чем тратить потенциально бесконечное количество времени на отслеживание потоков данных между внутриигровыми и/или относящимися к UE3 структурами.

Часть 2 Приглядимся внимательнее к D3DX

Сделав шаг назад, мы поняли, что ранее кое-что упустили. Вспомним, что для исправления игры нужно добавить в реестр одну из двух записей DisablePSGP и DisableD3DXPSGP. Если предположить, что их названия говорят об их назначении, то DisableD3DXPSGP должен быть подмножеством DisablePSGP, причём первый отключает PSGP только в D3DX, а последний и в D3DX, и в D3D. Сделав такое предположение, обратим своё взгляд на D3DX.

Mass Effect импортирует набор функций D3DX, компонуя d3dx9_31.dll:

D3DXUVAtlasCreateD3DXMatrixInverseD3DXWeldVerticesD3DXSimplifyMeshD3DXDebugMuteD3DXCleanMeshD3DXDisassembleShaderD3DXCompileShaderD3DXAssembleShaderD3DXLoadSurfaceFromMemoryD3DXPreprocessShaderD3DXCreateMesh

Если бы я увидел этот список, не зная информации, полученной нами из захватов, то предположил бы, что вероятными виновниками могут быть D3DXPreprocessShader или D3DXCompileShader шейдеры могли быть неверно оптимизированы и/или скомпилированы на AMD, но их починка может быть безумно сложной задачей.

Однако у нас уже есть знания, поэтому для нас из списка выделяется одна функция D3DXMatrixInverse является единственной функцией, которую можно использовать для подготовки констант пиксельного шейдера.

Эта функция вызывается только из одного места в игре:

int __thiscall InvertMatrix(void *this, int a2){  D3DXMatrixInverse(a2, 0, this);  return a2;}

Однако оно реализовано не очень хорошо. Краткое изучение d3dx9_31.dll показывает, что D3DXMatrixInverse не трогает выходные параметры и в случае невозможности инверсии матрицы (потому что входящая матрица вырожденная) возвращает nullptr, однако игру это совершенно не волнует. Выходная матрица может остаться неинициализированной, ай-яй! На самом деле инвертирование вырожденных матриц происходит в игре (чаще всего в главном меню), но что бы мы ни делали для того, чтобы игра обрабатывала их лучше (например, обнуляли выходные данные или присваивали им единичную матрицу), графически ничего не менялось. Вот так дела.

Опровергнув эту теорию, мы вернулись к PSGP что же конкретно PSGP делает в D3DX? Рафаэль Ривера изучил этот вопрос, и логика этого конвейера оказалась довольно простой:

AddFunctions(x86)if(DisablePSGP || DisableD3DXPSGP) {  // All optimizations turned off} else {  if(IsProcessorFeaturePresent(PF_3DNOW_INSTRUCTIONS_AVAILABLE)) {    if((GetFeatureFlags() & MMX) && (GetFeatureFlags() & 3DNow!)) {      AddFunctions(amd_mmx_3dnow)      if(GetFeatureFlags() & Amd3DNowExtensions) {        AddFunctions(amd3dnow_amdmmx)      }    }    if(GetFeatureFlags() & SSE) {      AddFunctions(amdsse)    }  } else if(IsProcessorFeaturePresent(PF_XMMI64_INSTRUCTIONS_AVAILABLE /* SSE2 */)) {    AddFunctions(intelsse2)  } else if(IsProcessorFeaturePresent(PF_XMMI_INSTRUCTIONS_AVAILABLE /* SSE */)) {    AddFunctions(intelsse)  }}

Если PSGP не отключен, то D3DX выбирает функции, оптимизированные под использование конкретного набора команд. Это логично и возвращает нас к исходной теории. Как оказалось, в D3DX есть функции, оптимизированные под AMD и набор команд 3DNow!, поэтому игра, в конечном итоге, всё-таки косвенно их использует. Современные процессоры AMD, в которых отсутствуют команды 3DNow!, идут по тому же пути, что и процессоры Intel то есть, по intelsse2.

Подведём итог:

• При отключении PSGP и Intel, и AMD проходят по обычному пути выполнения кода x86.
• Процессоры Intel всегда проходят по пути кода intelsse2².
• Процессоры AMD с поддержкой 3DNow! проходят по пути выполнения кода amd_mmx_3dnow или amd3dnow_amdmmx, а процессоры без 3DNow проходят по intelsse2.

Получив эту информацию, мы выдвинем гипотезу вероятно, что-то не так с командами AMD SSE2, и результаты инвертирования матрицы, вычисляемые на AMD по пути intelsse2, или слишком неточны, или полностью неверны.

Как нам проверить эту гипотезу? Тестами, естественно!

P.S.: Вы можете подумать в игре используется d3dx9_31.dll, но последняя библиотека D3DX9 имеет версию d3dx9_43.dll, и, скорее всего, эту ошибку устранили в более новых версиях?. Мы попробовали проапгрейдить игру, чтобы она компоновала самую новую DLL, но ничего не изменилось.

Часть 3 Независимые тесты

Мы подготовили простую независимую программу для проверки точности инвертирования матриц. На протяжении короткой игровой сессии в месте возникновения бага мы записали все входящие и выходящие данные D3DXMatrixInverse в файл. Этот файл считывается независимой тестовой программой, а результаты пересчитываются заново. Для проверки правильности выходные данные игры сравниваются с данными, вычисленными тестовой программой.

После нескольких попыток на основании данных, собранных с чипов Intel и AMD со включенным/отключенным PSGP мы сравнили результаты разных машин. Результаты показаны ниже с указанием успешных (, результаты равны) и ошибочных (, результаты не равны) прогонов. В последнем столбце указано, обрабатывает ли игра данные правильно, или глючит. Мы намеренно не учитываем неточность вычислений с плавающей запятой и сравниваем результаты при помощи memcmp:


Результаты тестов D3DXMatrixInverse

Любопытно, результаты демонстрируют, что:

• Вычисления с SSE2 не переносятся между машинами с Intel и AMD.
• Вычисления без SSE2 переносятся между машинами.
• Вычисления без SSE2 принимаются игрой, несмотря на то, что отличаются от вычислений на Intel SSE2.

Поэтому встаёт вопрос: что же конкретно не так с вычислениями с AMD SSE2, из-за чего они приводят к глитчам в игре? У нас нет на него точного ответа, но похоже, что это результат двух факторов:

• Реализация D3DXMatrixInverse на SSE2 может быть плохой численно похоже, некоторые команды SSE2 дают разные результаты на Intel/AMD (вероятно, из-за разных режимов округления), а функция написана так, что не может устранять эти неточности.
• Код написан таким образом, что он слишком чувствителен к проблемам с неточностью.

На данном этапе мы уже готовы создать исправление, которое заменит D3DXMatrixInverse на переписанную x86-вариацию функции D3DX, и на этом закончить. Однако у меня возникла ещё одна случайная мысль D3DX устарел и был заменён на DirectXMath. Я решил, что если уж мы всё равно хотим заменить эту матричную функцию, то можно поменять её на XMMatrixInverse, которая является современной заменой функции D3DXMatrixInverse. В XMMatrixInverse тоже используются команды SSE2, то есть она будет такой же оптимальной, как и с функцией из D3DX, но я был почти уверен, что ошибки в ней будут такие же.

Я быстренько написал код, отправил его Рафаэлю, и

Он отлично заработал! (?)

В конечном итоге, то, что мы считали проблемой, возникающей из-за небольших отличий команд SSE2, может быть исключительно численной проблемой. Несмотря на то, что XMMatrixInverse тоже использует SSE2, она дала идеальные результаты и на Intel, и на AMD. Поэтому мы заново прогнали те же тесты и результаты оказались неожиданными, если не сказать больше:


Результаты тестов с XMMatrixInverse

Игра не только хорошо работает, но и результаты идеально совпадают и переносятся между машинами!

Учтя это, мы пересмотрели свою теорию о причинах бага без всяких сомнений, в нём виновата игра, слишком чувствительная к проблемам; однако после проведения дополнительных тестов нам показалось, что D3DX писался под быстрые вычисления, а DirectXMath больше волнует точность вычислений. Это выглядит логично, ведь D3DX продукт 2000-х и вполне разумно, что его основным приоритетом была скорость. DirectXMath был разработан позже, поэтому авторы могли уделить больше внимания точным, детерминированным вычислениям.

Часть 4 Соединяем всё вместе

Статья оказалась довольно длинной, надеюсь, вы не устали. Подведём итог тому, что мы сделали:

• Мы убедились, что игра не использует команды 3DNow! напрямую (их используют только системные DLL).
• Мы выяснили, что отключение PSGP устраняет проблему на процессорах AMD.
• При помощи PIX мы нашли виновника значения NaN в константах пиксельного шейдера.
• Мы нашли источник этих значений D3DXMatrixInverse.
• Мы изучили эту функцию и выяснили, что она не даёт одинаковых результатов на процессорах Intel и AMD, когда используются команды SSE2.
• Мы случайно обнаружили, что XMMatrixInverse не имеет этого недостатка и является вполне достойной заменой.

Единственное, что нам осталось реализовать правильную замену! Здесь на сцену выходит SilentPatch for Mass Effect. Мы решили, что самым чистым решением этой проблемы будет создание подменной d3dx9_31.dll, которая будет перенаправлять все экспортированные Mass Effect функции на системную DLL, за исключением функции D3DXMatrixInverse. Для этой функции мы разработали замену на основе XMMatrixInverse.

Заменная DLL обеспечивает очень чистую и надёжную установку, она отлично работает с версиями игры с Origin и Steam. Её можно использовать сразу, без необходимости ASI Loader или любого другого стороннего ПО.

Насколько мы понимаем, теперь игра выглядит так, как должна, без малейшего ухудшения освещения:



Новерия



Илос

Загрузки

Модификацию можно скачать в Mods & Patches. Нажмите сюда, чтобы сразу перейти к странице игры:

Скачать SilentPatch for Mass Effect

После скачивания достаточно извлечь архив в папку игры, и на этом всё! Если не знаете, что делать дальше, то прочитайте инструкции по настройке.

---

Полный исходный код мода опубликован на GitHub и его можно свободно использовать как отправную точку:

Исходники на GitHub

Примечания

1. Теоретически, это также мог быть баг внутри d3d9.dll, что немного усложнило бы ситуацию. К счастью, это было не так.
2. Разумеется, если предположить, что у них есть набор команд SSE2, но любой процессор Intel без этих команд намного слабее, чем минимальные системные требования Mass Effect.

Я планировал написать эту статью еще весной 2020-го, но постоянно откладывал её в дальний ящик. Хотелось бы сказать, что причиной тому экологическая ситуация в стране и мире, но на самом деле желание накопить больше практического и тестового материала и, что поделать, безграничная прокрастинация. Теперь же, когда отдел маркетинга пишет мне чаще, чем кредиторы, и, по всей видимости, скоро начнет приходить домой справляться о самочувствии, я решил, что откладывать больше некуда. Тем более, что опыта накопилось достаточно, а AMD выпустил процессоры на новой архитектуре Zen 3.

Изначально в статье хотелось столкнуть лбами двух производителей AMD и Intel. Но все сроки были упущены. Поэтому вместо того, чтобы явно сравнивать красных и синих, протестируем два поколения Ryzen на Zen 2 и Zen 3. Справедливости ради и об Интел не забудем. Тем более, что исторически мы всегда предлагали серверы именно на их процессорах как серверных, так и десктопных. И статьи с тестами выпускали исключительно про них же. Монополия Intel в линейке представленных у нас конфигураций закончилась примерно год назад в декабре 2019-го мы стали предлагать серверы на базе AMD Ryzen 7 3700X и AMD Ryzen 9 3900X, затем в октябре 2020-го к ним добавился AMD Ryzen 9 3950X, а в декабре 2020-го и AMD Ryzen 9 5900X.

В общем, я решил, что процессоры обоих производителей на тестовом стенде может и не совсем вовремя, но точно неплохо.

Из истории моего знакомства с AMD

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

Для меня знакомство с продукцией AMD началось в далёком 2006 году, когда я будучи студентом первого курса устроился подмастерьем в сервисный центр и стал ремонтировать компухтеры. Тогда в моём личном пользовании находился домашний компьютер на процессоре Intel Pentium 4 531 на 3 ГГц, аж с Hyper-Threading. На фирменной материнской плате Intel, с SATA1, жёстким диском SATA на 80 Гб от Seagate и видеокартой ATI Radeon X300. На тот момент не самый топовый, но всё равно страшно крутой среди однокурсников компьютер, позволявший спокойно играть по сетке в CS 1.6.

Работая в сервисе, я впервые увидел компьютеры и ноутбуки на процессорах AMD (Athlon, Duron и Turion) по моему субъективному мнению, в городе их было примерно 50/50 с машинами на Intel. К тому же периодически встречались x86-совместимые процессоры VIA и Cyrix. Приблизительно в это же время появилась легенда о том, что АМД греются и даже сгорают от перегрева, что было в общем-то недалеко от правды. К слову, сей факт позволил компании Intel успешно пройти под радарами потребителя со всем ворохом технических и маркетинговых косяков, которые наблюдались при переходе от Pentium 4 к Core 2 Duo.

Пользуясь служебным положением, я достаточно быстро собрал личный компьютер на процессоре Intel Core 2 Duo E7200 на сокете LGA775 и материнской плате Asus так как десятками видел материнки Gigabyte на 478 сокете с прогаром в южном мосту. Меня всё устраивало, кроме того, что у процессора не было поддержки аппаратной виртуализации и появившийся тогда VirtualBox работал очень неспешно. Я перешёл на AMD Athlon II X2 и благодаря прямой и обратной совместимости сокетов имел шикарную возможность спокойно обновляться в течение пары лет. Intel этим похвастаться не мог.

Позже я пересел на AMD Phenom II X6, и это было что-то невероятное! Gentoo Linux, которая тогда была моей основной ОС, компилировалась меньше суток! Такой результат не удавалось получить никому из моих коллег на Intel Core 2 Quad. До опредёленного момента я считал, что это апофеоз компьютерной мысли. Пока поставщик не предложил новые AMD FX-8100 на микроархитектуре Bulldozer. Восемь ядер, не каких-то там жалких шесть! И я обновился Скорость пересборки мира упала, а я узнал, что процессор может перегреваться на боксовом охлаждении. Позже я обновился ещё пару раз FX-8150, FX-8300 и остановился на AMD FX-8350 на микроархитектуре Piledriver, причём с обновлением материнской платы (сокет AM3+). Но это всё равно было уже не то. Поэтому в моей памяти линейка Phenom II X6 так и осталась лучшей у AMD на многие годы.

Время шло, юношеские прыщи сошли на нет, Gentoo Linux подвинула Fedora Linux, и необходимость в повседневном компиляте отпала. Я смирился с прошлым, обзавёлся семьей, и, как следствие, лишился возможности постоянного апгрейда личной техники. За выходом новых линеек AMD наблюдал уже без особого энтузиазма, а потом и вовсе переехал на продукцию компании Apple, закончил карьеру сервисника и админа локалхоста и потерял связь с десктопами. История стала легендой, легенда фарсом. А потом уже и анекдотов насочиняли.

И вот в 2018 году АМД выпускает новое поколение процессоров на архитектуре Zen. Я аж весь оживился: что-то новое после стольких лет стагнации. Уже тогда я работал тут, где работаю, и как писал выше, имел дело только с процессорами Intel. Правда, надеясь, что однажды мы станем предлагать конфигурации на базе AMD.

И вот моя призрачная надежда внезапно становится реальностью. Не без моего участия, естественно.

Вспоминая историю с FX-8100, начать было решено с Райзенов третьей тысячи, тесты которых показали, на мой взгляд, просто шикарные результаты. А теперь вышла новая линейка процессоров на архитектуре Zen 3, которую тоже не обошла участь быть протестированной.

Так вот, уважаемый читатель, отбрось субъективизм и скепсис. Потому что, несмотря на всю свою неподдельную любовь к процессорной продукции компании AMD, которая после многолетнего технического простоя начинает почти с нуля отвоёвывать рынок, я за объективный подход за меня всё скажут результаты тестов.

Пара слов о техпроцессе и нанометрах

Многие, и мы в том числе, неоднократно сетовали на то, что Интел давно застрял на своих 14 нм. Доказательством тому были частые разговорчики типа: А у АМД уже давно 7 нм. А скоро будет ещё меньше.... Я решил немного разобраться в вопросе, поэтому вот моя краткая ремарка о техпроцессе и влиянии заявленных нанометров на производительность процессора.
Важной характеристикой для сравнения техпроцессов всё же остается число транзисторов на квадратном миллиметре. То есть сколько в кристалле процессора простейших логических элементов. Дело в том, что техпроцесс говорит не о размере самого транзистора, а о размере одной из его частей а именно затвора (насколько я себе это представляю). Остальные же составляющие элементы транзистора строго к величине техпроцесса не привязаны.

Ранее, на мой взгляд, до появления такой технология как FinFET, в которой стали использоваться трёхмерные, а не планарные транзисторы, ещё имело смысл сравнивать техпроцессы производителей, отталкиваясь от размеров транзистора. Но после производители пошли в разные стороны, разрабатывая собственные технологические решения. И нанометры из реального показателя превратились в абстрактный. При этом привычка сравнивать техпроцессы никуда не делась, хотя всё свелось к сравнению мягкого с тёплым. Теперь ориентироваться на размер заявленного техпроцесса даже не столько бессмысленно, сколько не очень показательно. И стоит сравнивать совсем другие параметры.

Например, в этой статье автор даёт интересную таблицу по сравнению техпроцессов:


Источник www.hardwareluxx.ru

• Fin Pitch: расстояние между ребрами (эмиттер и коллектор) транзистора
• Min Metal Pitch: минимальное расстояние между двумя слоями металла
• Fin Height: высота ребер от подложки Si в слое оксида
• Fin Width: толщина ребер

Между транзисторами на подложке тоже есть расстояние. И, надо заметить, что оно различается у таких производителей, как Samsung, TSMC, Intel и GF, при одной и той же заявленной величине техпроцесса.

В итоге получается, что понятие техпроцесса в один прекрасный момент стало сугубо маркетинговым и не говорит, как в былые времена, о техническом преимуществе процессоров, у которых он меньше. Таким образом, техпроцесс TSMC 7nm FinFET, на котором изготавливаются два последних поколения процессоров AMD, нельзя с твёрдой уверенностью назвать лучшим относительно фирменного техпроцесса Intel 14 нм. Если хотите углубиться в тему, то вот вам одна интересная статья и познавательный видеоролик по этому поводу. А мы наконец-то переходим к тестированию.

Тестирование

В комментариях к предыдущей статье нас резонно упрекнули в использовании разных версий бенчмарков, что отражается на результатах тестов. Что тут сказать. Часто бывает так, что патроны только подвезли, а они уже кончились. В том смысле, что далеко не всегда есть возможность провести повторное тестирование для конкретных процессоров на актуальных версиях бенчмарков. Но в этот раз мне-таки удалось заполучить в руки полный боекомплект, поэтому далее сможете посмотреть не только результаты тестирования Geekbench четвертой версии, но и пятой.

И раз уж мы заговорили о том, что влияет на результаты тестирования, вспомнился мне один пример из жизни. Как-то одного метеоролога спросили в интервью Скажите, что влияет на прогноз погоды?, он ответил проще сказать, что не влияет. Так вот на результаты тестов не влияет фаза луны, но это не точно.

А если серьёзно, факторов, которые могут повлиять на итоговый результат тестирования, более чем достаточно. И это не только операционная система или дистрибутив Linux. Результат будет зависеть и от версии ядра ОС, версий системного софта, планок памяти, даже если они имеют одинаковые характеристики, чипсета, фаз питания процессора и их охлаждения, версии BIOS, версии бенчмарков, особенно пакета phoronix, обновление тестов которого происходят чаще, чем презентации Apple в 2020 году. Даже накопитель влияет, например, на прохождение теста phoronix Apache. В общем, масса условий, которые трудно повторить по прошествии времени. Поэтому по мере сил при тестировании стараемся создать максимально одинаковые условия для тех процессоров, результаты которых попадут в одну статью.

Особо хочу отметить следующий момент. Он относится в меньшей степени к процессорам Intel, много лет делающей рефреши одной и той же архитектуры, и в большей степени к процессорам AMD: после релиза процессоров первые результаты тестов хуже, чем результаты тех же тестов спустя год. Предполагаю, что это связано с добавлением поддержки соответствующих процессоров и оптимизаций в ядро, софт и бенчмарки. Именно поэтому сюда не попали результаты первых тестов процессоров AMD: они были хороши, но новые ещё лучше.
В этот раз мы всё перепроверили заново, чтобы читатель смог получить самые актуальные результаты тестов.

Итак, что же сегодня попало в наши цепкие лапы?

Во-первых, это два процессора AMD на архитектуре Zen 2 Ryzen 9 3900X и Ryzen 9 3950X. Честнее было бы сравнивать их с девятой тысячей процессоров Интел Core i9-9900K. Почти одногодки всё-таки. Но мы решили, что в сравнении примет участие другой представитель от Интела, а точнее Core i9-10900K, относительно топовый процессор для сокета 1151. С одной стороны, у нас уже есть сравнительные тесты i9-9900K и i9-10900K, с другой оба этих процессора построены на одной архитектуре. Так что все честно.

Также мы решили протестировать свежие AMD пятой тысячи платформы на их базе пополнили нашу линейку серверов совсем недавно, поэтому без традиционных тестов не обойтись. Проверять будем три процессора на архитектуре Zen 3: Ryzen 7 5800X, Ryzen 9 5900X, Ryzen 9 5950X.

Замечу, что мы сравниваем не просто процессоры одного производителя в виде рефрешей, как делали ранее. В этот раз у нас есть возможность, во-первых, сравнить процессоры двух разных производителей, а во-вторых, процессоры одного производителя на двух разных архитектурах.

В случае сравнения Intel и AMD разное ВСЁ: производитель, ядерная архитектура, техпроцесс, процессорный кэш, как по объёмам, так и по архитектуре исполнения, количественное и качественное решение исполнения ядер, частота процессоров, количество вычислительных блоков. Единственное, что объединяет данные процессоры это архитектура x86/x86_64. И то технически это не совсем верно. В случае сравнения процессоров AMD разных поколений: это две разные ядерные архитектуры. Ну и, пожалуй, мы сейчас объединим их своими тестами.

Стоит сказать пару слов о третьей и пятой тысяче процессоров AMD. Как утверждает компания, в линейке Zen 3 ей удалось совершить ещё больший скачок в производительности, чем при выпуске предыдущих поколений Ryzen. Благодаря этому новинки, по мнению производителя, должны стать самыми быстрыми решениями на рынке не только в вычислительных задачах, но и в играх. В AMD заявляют, что серьёзно переработали архитектуру кристалла, что позволило без повышения базовых частот на том же техпроцессе поднять общую производительность до 19% относительно Zen 2. Ну, будем посмотреть.

Итак, в тестировании участвуют шесть процессоров:

• Intel Core i9-10900K,
• AMD Ryzen 9 3900X,
• AMD Ryzen 9 3950X,
• AMD Ryzen 7 5800X,
• AMD Ryzen 9 5900X,
• AMD Ryzen 9 5950X.

В тестировании использовались только одноюнитовые серверы (1U). Все процессоры охлаждаются жидкостным охлаждением (далее водяное охлаждение, СВО, вода, водянка).

Процессоры AMD охлаждаются водой в классическом исполнение для 1U платформ. Процессор Intel охлаждается продвинутым жидкостным охлаждением кастомизированное решение собственного производства, о конфигурации которого мы по-прежнему не распространяемся. Иначе i9-10900K перегреваются. Ну хоть не горят.

Все тестовые экземпляры подведены под единый общий знаменатель: 1U, вода, одинаковая оперативная память на частоте 2933, один и тот же накопитель данных. Память с частотой 2933 это максимум для i9-10900K, при этом представленные Рязани поддерживают память и на 3200. А как известно, производительность AMD процессоров, в том числе в тестах, сильно зависит от частоты памяти. С нашей стороны это делается для того, чтобы, так сказать, сравнять шансы.

Процессоры AMD тестируются на одной и той же материнской плате с новым чипсетом.

И ещё один момент, на который хотелось бы обратить внимание.

Сравнение между собой процессоров AMD 9 3900X, AMD 9 3950X и AMD 9 5900X, AMD 9 5950X логично и понятно: последние правопреемники предыдущих. Но вот AMD 7 5800X выбивается из этого ряда. Дело в том, что в нашей тарифной линейке также присутствует AMD 7 3700X, который я с удовольствием бы сравнил с новым AMD 7 5800X. И это было бы также понятно. Увы, протестировать его в момент подготовки статьи возможности не было. Но раз есть результаты 5800Х, то почему бы ими не поделиться.


Тактико-технические характеристики платформ

Процессоры Intel i9-10900k

• Материнская плата: ASRockRack W480D4U
• Оперативная память: 32 Гб DDR4-2933 MT/s Kingston 2 штуки
• NVMe SSD-накопитель: 1 Тб Intel 665P

Процессоры AMD

• Материнская плата: ASRockRack X570D4U (bios beta)
• Оперативная память: 32 Гб DDR4-2933 MT/s Kingston 2 штуки
• NVMe SSD-накопитель: 1 Тб Intel 665P

Программная часть: ОС CentOS Linux 8 x86_64 (8.3.2011).
Ядро: 4.18.0-240.1.1.el8_3.x86_64
Внесённые оптимизации относительно штатной установки: добавлены опции запуска ядра elevator=noop selinux=0

Тестирование производится со всеми патчами от атак Spectre, Meltdown и Foreshadow, бэкпортироваными в данное ядро.

Список тестов, которые проводились:

1) Sysbench
2) Geekbench 4
3) Geekbench 5
4) Phoronix Test Suite

Результаты тестирования

5950Х лучше 3950Х на 160%.
5900Х лучше 3900Х на 166%.


5950Х лучше 3950Х 23,3%.
5900Х лучше 3900Х 20,7%.


5950Х лучше 3950Х 7,3%.
5900Х лучше 3900Х 8,7%.


5950Х лучше 3950Х 27,2%.
5900Х лучше 3900Х 25,8%.


5950Х лучше 3950Х 8,5%.
5900Х лучше 3900Х 10,8%.


5950Х проигрывает 3950Х 1,1%.
5900Х лучше 3900Х 0,2% (почти равны).


5950Х лучше 3950Х 1,4%.
5900Х лучше 3900Х 3,6%.


5950Х лучше 3950Х 8,1%.
5900Х лучше 3900Х 10,8%.


5950Х лучше 3950Х 3,0%.
5900Х лучше 3900Х 7,6%.


5950Х лучше 3950Х 16,1%.
5900Х лучше 3900Х 16,5%.


5950Х лучше 3950Х 17,3%.
5900Х лучше 3900Х 20,3%.


5950Х лучше 3950Х 2,3%.
5900Х лучше 3900Х 10,0%.


5950Х лучше 3950Х 21,7%.
5900Х лучше 3900Х 19,8%.



В целом, результаты получились предсказуемые последнее поколение пятитысячных AMD уверенно обходит своих предшественников и оставляет далеко позади относительно свежие интеловские Core i9-10900K. При этом стоит отметить, что Ryzen 9 3950X из третьей тысячи показал себя весьма достойно по результатам тестов Geekbench он занимает второе место после новинок, а в многопоточном тесте John the Ripper, который измеряет количество операций в секунду, обошел даже Ryzen 9 5950X.

Довольно интересно показал себя и Ryzen 7 5800X, ставший лидером не только по результатам тестов Geekbench как в однопоточном, так и в многопоточном режиме, но и в других тестах - на кодирование аудиоданных (encode mp3) и на количество запросов в секунду (Apache). К серверам с этим процессором я бы порекомендовал присмотреться более внимательно. Особенно, для обработки медиаконтента или в качестве веб-сервера.

Ну и раз мы пообещали сравнение с Intel, то пару слов скажу и о них. Судя по результатам тестов, у i9-10900K есть шанс побороться за первенство в однопоточных тестах Geekbench (вероятнее всего, благодаря паре дополнительных ГГц), но только с AMD третьей тысячи показатели пятой тысячи на порядок лучше. Причём даже третья тысяча делает i9-10900K в большинстве тестов.

Так как секретариат партии намекнул мне, что громкие ликования не в нашем стиле, просто спокойно выскажу свое мнение. На моя взгляд, Intel уже два года если и не является догоняющим, то как минимум идёт наравне с AMD в десктопном и игровом сегменте. Как только Intel выпускает новое поколение процессоров, AMD сразу бьёт эту карту. По всей видимости, превосходству синих над красными приходит конец. Красные же, на мой взгляд, как Феникс сгорели, когда выпустили серию FX, и переродились из пепла с выпуском Ryzen.

Как видите, моя неподдельная любовь к AMD вызвана не только романтическими чувствами, но и банальным холодным расчётом. Если вы следите за новостями, то, по данным от PassMark Software, в начале 2021 года компания AMD заняла 50,8% рынка процессоров для настольных ПК в мире. Доля Intel, соответственно, упала до 49,2%. Это значит, что конкуренция гигантов-производителей выходит на иной уровень, который будет держать в тонусе обе компании. Поэтому предполагаю, что 2021 год окажется не менее динамичным, чем ушедший 2020-й в плане прорывных новостей на рынке процессоров. Тем более, что обеим компаниям есть что улучшать Intel-таки предстоит разобраться с техпроцессом 10 нм, а AMD, как минимум, решить проблемы с поставками, чтоб не получилось так, как в декабре, когда не все получили то, что заказали.

В тестировании использовались серверы на базе процессоров AMD Ryzen и Intel Core с 1dedic.ru. Выделенные серверы с этими процессорами можно собрать в конфигураторе и заказать со скидкой 7% на выбранный период оплаты 1, 3, 6 или 12 месяцев по промокоду HABR1DEDIC21. Скидка не распространяется на дополнительные услуги, подключенные к серверу. Промокод действует до 28 февраля 2021 года.