21 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Кэш память шейдера AMD что это

Тема: Гайд для ноутбуков с AMD

Опции темы
Поиск по теме

Гайд для ноутбуков с AMD

Короче говоря, эта статья должна помочь тем, у кого ноутбук с двумя видеокартами, одна из которых — AMD (Хотя, может помочь и обладателям Nvidia. Если найдёте у себя похожие параметры)

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

Итак. Первым делом хочу подметить, что гайд для видеокарт AMD на драйвере «Crimson Edition» (Если вы до сих пор не обновили и сидите на каталисте — ничего страшного, ниже вы поймёте почему я придерживаюсь такого мнения)
Лично у меня самого стоит Кримсон 16.6.2 т.к. не всегда новое — хорошее (я сейчас серьёзно) Вложение 1352483 Именно 16.6.2 работает в разы лучше других версий. (Можете тоже попробовать именно её, просто загуглив «Crimson Edition 16.6.2 Release Notes»). Чтобы её поставить, скачайте драйвер под вашу систему (ниже, на странице рн), удалите ваш драйвер и установите данный. (НЕ ОБЯЗАТЕЛЬНО)

По настройкам вкладки «Игры»: Вложение 1352484 Объединил в красные квадратики схожие параметры (либо зависящие друг от друга)
Режим сглаживания: Использовать настройки приложения
Метод сглаживания: Множественная выборка
Морфологическая фильтрация: Откл.
Режим анизотропной фильтрации: Переопределить настройки приложения
Уровень анизотропной фильтрации: 2х
Качество фильтрации текстур: Производительность
Оптимизация формата поверхности: Вкл.
Ждать вертикального обновления: Выкл., если не указано приложением
Тройная буферизация OpenGL: Вкл.
Кэш-память шейдера Оптимизировано AMD (лучше иногда сбрасывать, желательно после 3-5 игр) сбросить можно в том же окне, сверху.
Режим тесселяции: Переопределить, уровень: Откл.

Далее, к самим настройкам, которые расположены внизу, на главном (домашнем) экране Вложение 1352486
Там, в первом же блоке, будет параметр «Дополнительные настройки Radeon» (Ненавижу его) Работает он не всегда. Иногда крашит, иногда зависает проводник, либо просто не открывается. А это действительно плохо. Ибо там есть важная часть настроек.

В этом меню (Буду называть его ССС — catalyst control center) нам будут нужны только три вкладки: Вложение 1352490
Кстати, как я написал в начале темы, у кого каталист — это не так плохо, ибо у кого ещё драйвер той версии, тот 100% сможет открыть эти вкладки.

Заходим в ССС и открываем вкладку «Питание» — PowerPlay и делаем вот таким образом: Вложение 1352491 (Подключено: Макс. производительность)
Идем во вкладку «Глобальные параметры переключаемой графики» — ОНА ТУТ САМАЯ ГЛАВНАЯ, И ОЧЕНЬ ВАЖНО ВЫБРАТЬ ПРАВИЛЬНЫЙ ВАРИАНТ!
ПОДКЛЮЧЕНО: ОПТИМАЛЬНОЕ ЭНЕРГОСБЕРЕЖЕНИЕ
Объясню, почему нужно выбрать именно этот параметр. Многие совершают ошибку. Видя слово «производительность» — думают, что станет шустрее. Однако, у вас есть две видеокарты, когда вы ставите на Оптимальное энергосбережение, то все процессы, которые вы вручную не поставили на игровую видеокарту, будут грузиться на интегрированную, тем самым, снимая лишнюю нагрузку с дискретной.
Тоже самое, что кошка будет ходить только на задних лапах, хотя есть передние. Зачем тратить ресурсы высокопроизводительного адаптера на то, что может взять на себя энергосберегающий? Да, не все задачи будут запускаться на игровой, но те, что используют 3D графику, или её элементы, вполне спокойно могут грузить вашу видяху.

Последняя вкладка в ССС — настройка видеокарты для приложений (вручную)
Тут всё просто: Скрываем список «Недавние» и разворачиваем «Все приложения» и жмём «Добавить приложение» Далее, просто идём к ехе-файлу нашей игры. По умолчанию: «SYS.D» (ваш диск)GamesMailRuWarfaceBin32ReleaseGame.exe
Ставим на производительность и всё. Пробуем после этого поиграть, даже если ничего не изменится с первого взгляда, то в разгар боя, или при работе в сторонних процессов во время игры, они могут лишний раз вас не тревожить.

Обладателям Nvidia — тоже самое, ищите у себя «Общий» параметр переключаемой графики и выбор приложений вручную. Ставьте по умолчанию на энергосбережение, а для игры — производительность.

Тест и обзор: AMD Radeon Software Crimson Edition – новое поколение драйверов

Страница 2: Новые функции

Кроме обновления внешнего вида и ряда улучшений, в Crimson Edition появились новые или переработанные функции:

  • Первый драйвер с поддержкой LiquidVR
  • FreeSync теперь работает под CrossFire и DirectX 9
  • FreeSync теперь можно использовать при подключении через HDMI
  • При активированном FreeSync больше не наблюдается резкого «выпадения кадров» при проседании fps ниже минимальной поддерживаемой частоты обновления, алгоритм пытается обеспечить fps видеокарты выше данного уровня через сглаживание частоты кадров (frame pacing)
  • Frame Pacing теперь работает под DirectX 9
  • FRTC можно регулировать от 20 до 200 fps
  • Flip Queue Size Optimization – ввод мыши и клавиатуры обрабатывается быстрее, задержки процесса рендеринга уменьшены
  • Crimson Edition в играх DirectX 12 до 20 процентов быстрее (Fable Legends)
  • На новых играх AMD планирует улучшить производительность на 3-15 процентов (ниже будут тесты)

Две или три особенности следует рассмотреть более внимательно. Прежде всего, радует возможность использования FreeSync в конфигурациях CrossFire. Многие наши читатели пользуются системами CrossFire, и в прошлом им приходилось жертвовать FreeSync, хотя эта технология была бы здесь как нельзя кстати. На Computex в этом году AMD уже демонстрировала работу FreeSync через HDMI. Но, в отличие от реализации через интерфейс DisplayPort, AMD не стала использовать открытое решение, поэтому не совсем понятно, как именно AMD реализует поддержку FreeSync через HDMI. И пока неизвестно, будет ли поддержка FreeSync добавлена к следующим версиям HDMI. Производителям мониторов вряд ли нравится опираться на проприетарные стандарты, как в случае G-Sync от NVIDIA. Кроме того, AMD будет противоречить сама себе, поскольку FreeSync продвигается как открытый стандарт.

Кроме того, при активном FreeSync и снижении частоты кадров ниже минимальной поддерживаемой частоты обновления больше не наблюдается «выпадения кадров», за что AMD ранее получала немало критики.

Кэш шейдеров (Shader Cache)

Кроме внешних изменений оболочки драйвера и многочисленных мелких улучшений AMD в Crimson Edition добавила новую функцию – кэш шейдеров (Shader Cache). Данная технология позволяет кэшировать скомпилированные шейдеры на HDD и SSD. Она работает в играх DirectX 10 и DirectX 11. Во многих играх уже скомпилированные шейдеры пересчитываются при каждом повторном запуске или при переходе на новый уровень, AMD теперь позволяет миновать данный промежуточный шаг, в результате игры должны загружаться быстрее (или быстрее загружать новый уровень). Поскольку шейдеры компилируются и во время игры, кэш шейдеров позволяет пропустить данный шаг, потенциально препятствуя снижению частоты кадров.

Кэш шейдеров в драйверах Crimson Edition можно активировать в настройках игры, где следует указать «оптимизация AMD». Мы проверили несколько игр с активным кэшем шейдеров и без него, ниже представлены результаты. Мы измеряли время запуска игры и время загрузки уровня – секундомер запускался при запуске исполняемого файла игры и останавливался, когда можно было уже играть.

AMD прощается с Catalyst: запущена новая программная платформа Radeon Software Crimson

В декабре 2014 года компания AMD выпустила крупное обновление драйверов Catalyst Omega, а спустя почти год решила навсегда отказаться от прежнего бренда, использовавшегося ей на протяжении тринадцати лет. Выпущенный сегодня пакет Radeon Software Crimson Edition включает новейший драйвер, а также первую редакцию новой программной платформы Radeon Software. Более современный, быстрый и удобный аналог Catalyst Control Center (CCC) разработан сформированным в прошлом месяце подразделением Radeon Technologies Group (RTG) и призван не только повысить качество ПО, но и увеличить экономию энергии и производительность в играх, а также улучшить качество воспроизведения видео, поддержку DirectX 12 и технологий виртуальной реальности.

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

Radeon Software предлагает следующие основные нововведения:

  • более быстрый интуитивный интерфейс, созданный с нуля;
  • менеджер игр;
  • поддержка технологии виртуальной реальности LiquidVR;
  • профили качества и новые функции, связанные с воспроизведением видео;
  • интеграция с социальными сетями;
  • упрощенная настройка технологии AMD Eyefinity для систем с несколькими дисплеями;
  • панель системных уведомлений;
  • кэширование шейдеров;
  • технология сглаживания кадровой частоты (Frame Pacing) версии 3.0;
  • возможность настройки различных параметров дисплея (Custom Resolutions);
  • улучшенная технология AMD Low Framerate Compensation (LFC) на дисплеях с поддержкой AMD FreeSync;
  • дополнительные возможности OpenCL 2.0.

Одна из особенностей Radeon Software — повышенная экономия энергии. По сравнению с AMD Catalyst 15.7.1 новая версия ПО позволяет в разы эффективнее расходовать ресурсы графического ускорителя и всей системы в целом при просмотре HD-видеороликов на YouTube.

Функция Frame Rate Target Control (FRTC), впервые представленная в AMD Catalyst 15.7, теперь позволяет вручную задавать кадровую частоту для полноэкранных приложений на базе DirectX 9. Пользователь может установить любое значение в пределах от 30 до 200 кадров/c. Эта возможность помогает снизить нагрузку на графический процессор и как следствие уменьшить уровень шума и нагрев. Управление кадровой частотой особенно пригодится в меню игр и на загрузочных экранах — в таких случаях изображение нередко обновляется несколько сотен раз в секунду.

Что касается игр на базе DirectX 10 и DirectX 11, то в BioShock Infinite на той же видеокарте в разрешении 4К при ограничении частоты до 60 кадров/с можно добиться экономии 105 Вт и 107 Вт для видеоускорителя и всей системы соответственно. Соответствующая функция в Catalyst 15.7.1 при этом экономит не более чем 50 Вт. В Sniper Elite 3 при установлении лимита 55 кадров/с экономия может достигать 189 Вт для графического адаптера и 190 Вт для всего компьютера.

Повышение производительности в играх

На Radeon R9 Fury Х в разрешении 1080р можно получить некоторый прирост производительности в играх по сравнению с Catalyst 15.7.1: в Fable Legends он составляет 20 %, в Call of Duty: Black Ops 3 — 8,22 %. Оптимизирована работа и некоторых игр на Linux (BioShock Infinite, Total War, Portal 2 и Dota 2 — рост производительности варьируется от 112 до 155 %).

Читать еще:  Steam API init failed что делать

Благодаря функции кэширования шейдеров во многих играх, особенно имеющих открытый мир, удаётся добиться сокращения времени загрузок, устранить «заикания» изображения из-за перегрузки ЦП и кратковременные зависания. Так, при включении этой опции загрузка бенчмарка BioShock Infinite ускоряется на 12 %, а карты Эндор в режиме «Выживание» в Star Wars: Battlefront — на 34,5 % (Radeon R9 380X, AMD FX 8370, 8 Гбайт оперативной памяти, Windows 10).

Также обновление привнесло поддержку функции сглаживания кадров (Frame Pacing), введённой в Catalyst 13.12, для игр на DirectX 9 (на графике ниже результаты её работы показываются на примере The Elder Scrolls V: Skyrim) и улучшило работу технологии динамической вертикальной синхронизации FreeSync при частых падениях кадровой частоты. Технология Low Framerate Compensation (LFC) на дисплеях с поддержкой FreeSync сглаживает скачки кадровой частоты и устраняет «дрожание» картинки.

Кроме того, Radeon Software предлагает шесть профилей для просмотра видеороликов, которые автоматически активируют определённые возможности в зависимости от текущего разрешения экрана, воспроизводимого контента и используемого проигрывателя. Пользователи могут настраивать резкость, яркость, цветовую насыщенность, а также активировать режимы AMD Fluid Motion Video и AMD Steady Video.

Также появились две новые функции: направленное масштабирование (Directional Scaling), сглаживающее возникающий при выводе изображения в 1080р на 4К-дисплее «лестничный эффект» , и адаптивное управление динамической контрастностью, позволяющее повысить общий контраст изображения, не затрагивая тёмные области.

Наконец, теперь у пользователей появилась возможность вручную задавать различные параметры дисплея: горизонтальное и вертикальное разрешение, частоту обновления, частоту пикселизации, тип развёртки и пр.

В пакет входит программа AMD Unistall Clean Utility, которая удалит ранее установленные графические и звуковые драйверы Catalyst, неиспользуемые файлы и записи в реестре.

Одновременно с выпуском Radeon Software Crimson Edition компания поделилась любопытной статистикой и некоторыми планами на будущее. Выяснилось, что с момента выпуска AMD Catalyst Omega драйверы для видеокарт её производства были загружены свыше 60 млн раз. В следующем году компания, как уже отмечалось в прошлом, будет выпускать обновления драйверов чаще: в 2016-м появятся вплоть до шести WHQL-редакций драйверов, тогда как в 2015-м их было три. Наряду с основными релизами AMD, как и прежде, намеревается выпускать бета-драйверы.

Скачать пакет можно с официального сайта производителя. Он предназначен для 64- и 32-разрядных версий Windows 10, Windows 8.1 и Windows 7, а также Linux. Список поддерживаемых видеокарт для настольных систем начинается серией AMD Radeon HD 7700 и заканчивается AMD Radeon R9 Fury (для ноутбуков — от AMD Radeon HD 7700М до AMD Radeon R9 M300).

Compute shader 3: кэши CPU и GPU

Похоже, у меня получился небольшой сериал про Compute shader, и на этой неделе я собираюсь закончить его, обсудив вычислительные блоки и кэши. Настоятельно рекомендую сначала ознакомиться с первой и второй частью, потому что я часто буду на них ссылаться. Кэши или вычислительные блоки, с чего бы начать? Возьмем сначала блоки.

Исполнительные порты

Если вы знакомы с современным дизайном CPU, вы знаете, что он не является скалярным устройством, обрабатывающим по одной инструкции за раз. В современной архитектуре наподобие Zen имеется 10 исполнительных портов. Часть из них целочисленные, а часть — для операций с плавающей точкой:

У Zen есть десять вычислительных блоков: для операций с плавающей точкой и целочисленных.

GPU также получают выгоду от наличия множества исполнительных портов, но не в том же смысле, что CPU. На процессоре инструкции выполняются не по порядку, а некоторые из них — спекулятивно. Такое невозможно для GPU. Для всего “железа” с выполнением не по порядку и переименованием регистров требуется еще больше регистров, а графические процессоры уже имеют тысячи (например, у Vega10 на кристалле 16 Мбайт регистров). Не говоря уже о том, что спекулятивное исполнение увеличивает потребление энергии и это уже сильно ограничивающий фактор для графических процессоров, работающих с очень большими рабочими нагрузками. Наконец, программы GPU не выглядят так, как программы для процессоров. Порядок, спекуляции, предварительная выборка и т.д. хорош, если вы выполняете GCC, но не для старых добрых пиксельных шейдеров.

Как говорилось, очень разумно давать запросы к памяти в то время, пока SIMD заняты обработкой данных или по порядку выполняет скалярные инструкции. Так как мы можем получить эти выгоды не нарушая порядка? GPU превосходит CPU в том, что выполняет очень много работы в полете. Так же, как мы пользовались этой особенностью для сокрытия латентности, мы можем взять ее для планирования. В CPU мы смотрим вперед одного потока команд и пытаемся найти независимые команды. В GPU у нас есть тысячи независимых потоков команд. Самый простой способ получить параллелизм на уровне инструкций — просто иметь разные блоки для разных типов команд и выдавать инструкции соответственно. Оказывается, именно так построен GCN, с несколькими портами выполнения за такт:

GCN имеет несколько портов исполнения на один такт: скалярный ALU/скалярная память, ветки/сообщения, Векторный ALU, LDS, экспорт/GDS и векторная память.

Всего есть шесть различных портов исполнения, и диспетчер может отправлять по одной инструкции в такт максимум на пять из них. Существуют особые инструкции, передаваемые диспетчером непосредственно (например, NOP отправлять в блок совершенно бесполезно). На каждом такте диспетчер просматривает активные вейвы и на следующую готовую к исполнению инструкцию. К примеру, давайте предположим, что для выполнения у нас есть следующий код:

Если готовы два вейва, диспетчер отправит первый v_add в первый SIMD. В следующем такте он получит s_cmp из первого вейва и v_add со второго. Таким способом скалярные команды перекрывают выполнение векторных, и мы получаем параллелизацию на уровне инструкций без забеганий вперед и дорогих неупорядоченных вычислений.

Давайте рассмотрим более сложный пример, в котором несколько вейвфронтов выполняют скалярные и векторные команды, а также запросы к памяти:

В верхней части показано, как распланированы вейвфронты (такты идут слева направо). В первом такте три независимые команды передаются трем блокам. Не забывайте, что VALU работает четыре такта. В нижней части показывается, насколько сильно загружены блоки. Поскольку команды в VALU исполняются в течение четырех тактов, все четыре блока SIMD становятся задействованными очень быстро. Добротная смесь команд гарантирует, что будут заняты все блоки.

Перед там, как закончить, надо рассмотреть еще обработку загрузки и хранение. В CPU все прозрачно, так что вы можете написать последовательность следующим образом:

Это работает, потому что проследив за этой информацией CPU “знает”, что загрузка должна завершить до того, как начнется выполнение операции. В GCN ISA для ожидания пока не завершится несколько загрузок используется специальная команда s_waitcnt. Это не просто ожидание всего что угодно, команда позволяет передать по конвейеру одновременно несколько загрузок и затем употребить их одну за другой. Соответствующие действия у GCN ISA будут выглядеть примерно так:

Я думаю, было бы правильно считать (GCN) GPU как CPU, выполняющий по четыре потока на ядро (вычислительный блок), и каждый поток может выполнять скалярные, векторные и иные команды. Это нормально, а разработчики сделали компромисс между сложностью программного и аппаратного обеспечения. Вместо сложных аппаратных средств GPU нужно солидное программное обеспечение для параллельных вычислений. Не только чтобы спрятать латентность, но и для лучшей загрузки всех вычислительных блоков. Вместо “автоматического” слежения все это требует от компилятора добавлять дополнительные команды, а приложение должно обеспечить достаточную параллельность. Но вместе с тем мы получаем огромную пропускную способность и тысячи вычислительных блоков. Вот хороший пример того, как особенности исполняемого кода могут повлиять на дизайн аппаратных средств.

Если говорить о том, как программные средства влияют на аппаратные, нельзя не упомянуть о кэшах. Кэши GPU это еще один — и последний в этой серии — пример того, как графический процессор сконструирован специально для большого объема параллельной работы, и на какие компромиссы для этого пришлось пойти конструкторам. Мы также обнаружим, что CPU на самом деле следует по пути, аналогичному GPU!

Давайте сначала посмотрим, как выглядят современные процессоры, например 32-ядерный серверный процессор архитектуры Zen:

Современный серверный процессор на архитектуре Zen. Конфигурация содержит четыре матрицы, в каждой из которых по два комплекса ядер. В каждом комплексе ядер есть 8 MiB кэша L3, 4 кэша L2 по 512 KiB каждый, 4 кэша L1 по 32 KiB каждый и 4 командных кэша по 64 KiB каждый. Это очень много кэша — только на L3 в общей сложности приходится 64 MiB!

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

Что это значит для разработчика приложений? Это значит, что выполнение всех команд в приложении должно быть “близко”. Обычно за этим следит планировщик ОС. По умолчанию все кэши когерентны друг с другом. То есть когда ядро в левом верхнем углу пишет что-либо в память, это видит ядро в нижнем правом углу. Для этого были разработаны различные протоколы. Суть в том, что любое ядро может записывать в память, и любое другое ядро увидит новые данные по умолчанию. Никакой дополнительной работы от приложения — но вы можете себе представить, что обмен данными между ядрами потребовал бы очень много работы.

Итак, в GPU проходит намного больше параллельных процессов, чем в CPU. Графический процессор Vega10, технически говоря, является 64-ядерным CPU в похожей иерархией кэша. Давайте посмотрим на него:

Vega10 GPU, состоящий из 4 шейдерных движков. Каждый шейдерный движок содержит 16 вычислительных блоков. Вычислительный блок имеет 16 KiB кэша L1, четыре вычислительных блока имеют общий 32 KiB командный кэш и 16 KiB скалярного (константого) кэша. Все шейдерные движки соединены с 4 MiB кэшем L2.

Размеры абсолютно иные, но смутное подобие имеется. Если достаточно поднапрячься, можно представить, что перед нами 64-ядерный процессор на одном кристалле. Очевидно, дьявол снова скрывается в деталях, потому что CPU имеют согласованность по умолчанию, а GPU работают в совершенно другом режиме. Его устройство оптимизировано под выполнение многих независимых задач, поэтому давайте подумаем, как это повлияет на кэш. Учитывая, что каждый рабочий элемент является независимым, мы можем предположить, что каждое ядро ​​работает с собственными данными, и между ядрами практически нет общего доступа. Как мы можем оптимизировать оборудование для этого? Прежде всего, мы избавимся от согласованности по умолчанию. Если ядро ​​A что-то пишет и хочет, чтобы ядро ​​B его увидело, теперь это ответственность разработчика. Предполагается, что такое редко необходимо, так как потребуется две синхронизации: одна в памяти (нам нужно как-то стереть данные из кэша), а вторая — чтобы второе ядро как-то обрабатывало те же данные. Как мы узнали, графические процессоры обычно не особо любят соблюдать порядок выполнения, и это напрямую влияет на обработку кеша. Поскольку синхронизация легла на разработчика, GPU для поддержки могут создавать барьеры памяти.

Читать еще:  Принудительное удаление файлов Windows 7

А еще кэши не управляют собой. В CPU все, как правило, работает только в рамках одного процесса, но на графическом процессоре скрытые и недействительные кэши являются очень явной операцией. Если вы закончите один вычислительный шейдер и хотите начать следующий, GPU обычно сбрасывает и аннулирует все локальные кеши вычислительного блока, чтобы все работы были гарантированно завершены и следующая отправка увидела данные. Из-за этого крайне важно сохранить данные в L2: очистка кэшей L1 происходит очень часто, но дешево, потому что они маленькие. Сравните это с процессором, где L2 одного ядра вдвое меньше всех вместе взятых кэшей L1 в GPU!

Также интересные общие кэши. В случае CPU общие данные есть только в L3. В GPU, где одна программа будет выполняться многими вычислительными блоками, кэш инструкций является общим для них. Это означает, что в идеале мы хотим отправить одну и ту же программу в группы из четырех вычислительных блоков, а не полностью случайно по GPU. Точно так же мы предполагаем, что одни и те же константы загружаются по всем вэйвам, выполняющим одну программу, что отражено в наличии кэшей констант (скалярных кэшей). Практически, те доступны только для чтения (исключая атомарные инструкции), и означит, что их не нужно очищать (изменять данные), но все равно надо объявлять недействительными между отправлениями.

Вы можете задаться вопросом: как при таких настройках по умолчанию добиться согласованности кэшей? Разумеется, способ есть, поскольку GLSL, например, имеет когерентный модификатор. Рад, что вы спросили — решение довольно простое. Все вычислительные блоки разделяют один L2, поэтому, если надо обеспечить согласованность, мы можем просто обойти L1. Если вы посмотрите на GCN GCA, там есть бит GLC, в котором говорится: «Принудительный обход кэша L1». Записывая в L2 и всегда читая из L2, мы можем создать видимость связных кэшей без какого-либо протокола согласованности. Все за счет простого игнорирования (крошечного) L1 — опять-таки компромисса, который имеет смысл для графических процессоров.

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

Графические процессоры должны решать другую проблему. Тонны потоков в полете, все они хотят либо передавать данные, либо получать доступ к данным пространственно-согласованным способом (например, к текстурам). Для этого варианта использования в реальности надо использовать кеш, который поможет комбинировать чтения / записи и хранить данные достаточно долго, чтобы переместить их в регистры. Например, вы поэлементно загружаете 4 компонентный вектор. В идеале нужно, чтобы четыре компонента были «кэшированы» пока загрузка не закончится. Крошечный кеш идеально подходит для этого — он поддерживает кэширование линии до тех пор, пока ее не употребят, и вероятность того, что вы попадете в тот кэш снова, очень мала, так как потоки обрабатывают тонны (независимых) данных. В данной серии статей это был последний пример, как исполняемый код и его предполагаемое использование сделали GPU очень отличным от CPU.

Заключение

Вот и все, ребята! Надеюсь, вам понравилась серия, и вы заметили, что CPU и GPU оба многоядерные, но каждый специально разработан и настроен для разных вариантов использования. Другая интересная вещь — это то, как модель программирования повлияла на аппаратный дизайн и наоборот — и как мы находимся на пути к конвергенции. Код современного GPU, как правило, отлично работает на современных процессорах. Он достаточно хорошо написан, чтобы использовать преимущества многих ядер, может обрабатывать неравномерный доступ к памяти и легко справляться с малыми гарантиями попадания в кэш. Куда мы направляемся? Я не знаю, но знания о вычислительных шейдерах и моделях исполнения GPU помогут подготовиться к тому, что впереди!

Компиляция шейдерного кэша для CRYENGINE 5.3. Оптимизация CRYENGINE 5.

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

Официальная документация по теме:

Предусмотрено два режима работы с шейдерным кэшем:

1. Использование заранее скомпилированного шейдерного кэша, который создаётся по списку шейдерных комбинаций shaderlist.txt , встречающихся на уровнях игры. Это наиболее предпочтительный режим для релизной сборки игры.

Когда отключена компиляция шейдер ного кэша на ходу , то движок будет брать шейдерный кэш из global shader cache, к оторый является содержимым engine

shadercache.pak

shadercachestartup.pak

shadersbin.pak

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

Так же в engine можно увидеть engine.pak и shaders.pak.

engine.pak — здесь содержаться различные конфигурационные файлы и некоторые базовые ресурсы для движка.

shaders.pak — это непосредственно шейдеры движка в бинарном формате. Важно не путать шейдерный кэш и сами шейдеры .

Из shaders.pakHWScriptsCryFX можно удалить исходники шейдеров с расширением .cfi и .cfx.

2. Компиляция шейдерного кэша на ходу осуществляется во время игры по необходимости. У этого режима основными недостатками являются работа только в Windows и кратковременные, но сильные подтормаживания, вызываемые пиковыми загрузками CPU под 100% во время компиляции шейдерных комбинаций.

Чтобы в ключить компиляцию шейдер ного кэша и выключить подгрузку из shadercache.pak , shadercachestartup.pak и shadersbin.pak необходимо прописать в system.cfg :

r_ s hadersAsyncCompiling= 3

В релизной сборке игры должны быть отключены (задать нулевое значение).

Если включена компиляция шейдерного кэша на ходу, то движок не будет подгружать шейдерный кэш из global shader cache = shadercache.pak, shadercachestartup.pak и shadersbin.pak.

Применение Remote Shader Compiler.

Когда компиляция шейдер ного кэша включена r_shadersAsyncActivation=1, а дистанционная компиляция отключена r_shadersRemoteCompiler=0, то шейдер н ы й к эш буд е т сохраняться локально в usershaders cache .

Локально скомпилированны й шейдер н ы й кэш ( без использования Remote Shader Compiler ) р абота е т только для DX-рендера на Win dows , следовательно, для Linux и консолей необходимо осуществлят ь компиляцию дистанционн ым компиля тором шейдерного кэша r_shadersRemoteCompiler=1 .

Локально скомпилированны й шейдер н ы й кэш не буд е т работать , если его упаковать в shadercache.pak , shadercachestartup.pak и shadersbin.pak , поэтому необходимо использовать дистанционный компилятор шейдер ного кэшаRemote Shader Compiler.

Дистанционный компилятор шейдер ного кэша (Remote Shader Compiler) находится в ToolsRemoteShaderCompiler и называется CrySCompileServer.exe.

Запросы на дистанционную компиляцию выполняются параллельно, поэтому чем больше ядер у сервера, тем лучше. Сервером может выступать в том числе локальная машина.

Необходимо скопировать каталог RemoteShaderCompiler вместе с содержимым в каталог своего проекта/сборки игры в Tools . Впоследствии нужно будет включать CrySCompileServer.exe и запускать игру, чтобы начать компилировать комбинации шейдерного кэша, всё это будет описано ниже.

Настройка конфигурационного файла для Remote Shader Compiler.

Перед запуском дистанционного компилятора необходимо прописать настройки в его конфигурационный файл ToolsRemoteShaderCompiler config.ini .

Пример содержимого config.ini :

TempDir=C:SHADER_CACHE
port=31455
PrintErrors=1

Описание :

TempDir= C:SHADER_CACHE — каталог, куда буд е т сохраняться временный кэш в процессе компилирован и я . Можно указать любой желаемый, но без кириллицы в пути.
port=31455 — указать порт. По умолчанию 31455 или 61453.
PrintErrors=1 — выводить предупреждения.

Конфигурирование system.cfg для активации Remote Shader Compiler.

system.cfg должен быть в корне проекта/сборки игры.

Примечание: Для релизной сборки игры нужно будет подготовить system.cfg с такими параметрами, чтобы Remote Shader Compiler и компиляция шейдерного кэша на лету были выключены! Пример содержимого релизного system.cfg будет ближе к концу статьи.

Пример полного списка параметров system.cfg для работы с Remote Shader Compiler:

sys_game_folder=Assets
sys_dll_game=CryGameSDK
sys_localization_folder=languages
s_AudioImplName=CryAudioImplWwise
sys_spec=3

sys_no_crash_dialog=1
sys_vr_support = 0
log_IncludeTime=3
log_Verbosity=3

r_ShadersAsyncCompiling=3
r_ShadersRemoteCompiler=1
r_ShaderCompilerServer=192.168.1.3
r_ShaderCompilerPort=31455
r_ShadersAsyncMaxThreads=8
r_driver=DX11
r_ShadersDX11=1
— r_driver=GL
— r_ShadersGL4=1
r_ShadersUserFolder=1
r_ShadersSubmitRequestline=1

r_ShadersDurango=0
r_ShadersOrbis=0
r_multithreaded=0

Описание основных специфических параметров:

r_shadersAsyncActivation=1 — включить компиляцию шейдерного кэша на ходу.

r_ShadersAsyncCompiling=3 — метод асинхронной компиляции.

r_ShadersRemoteCompiler=1 — включить дистанционную компиляцию шейдерного кэша.

r_ShaderCompilerServer= — указать IP сервера для дистанционной компиляции, но можно компилировать локально без стороннего сервера, указав локальный IP. Узнать локальный IP можно через командную строку Windows (cmd.exe) с помощью команды ipconfig .

Если будет применяться несколько серверов дистанционных компиляторов, то прописывать их IP через точку с запятой без пробела: r_ShaderCompilerServer= ;

r_ShaderCompilerPort= — указать тот же порт, что и в config.ini. По умолчанию 31455 или 61453.

r_ShadersAsyncMaxThreads=8 — указать количество доступных потоков CPU для использования в расчётах.

r_driver=DX11 — ч тобы скомпилировать шейдеры под DX 11 (ShaderList_PC.txt).

r_ShadersDX11=1

r_driver=GL — ч тобы скомпилировать шейдеры под OpenGL (ShaderList_GL4.txt).

r_ShadersGL4=1

За раз может генерироваться только набор под одну выбранную платформу ( DX, OGL или под консоль). Платформа указывается в r_driver=

Осуществление компиляции.

Запускаем дистанционный компилятор шейдеров:

ToolsRemoteShaderCompilerCrySCompileServer.exe

Запускаем игру(!), а не через редактор, и проходим уровни , чтобы все возможные комбинации шейдеров были просчитаны. Если необходимые комбинации шейдеров не будут просчитаны, то объекты, использующие их, будут отображаться некорректно или не будут отображаться вовсе. Нужно пробежать все уровни на всех настройках графики и с применением (если будет использоваться) того или иного типа сглаживания ( FXAA, MSAA и прочие).

После пробежки по уровням закрываем игру.

Шейдерный кэш сформирован.

Упаковка шейдерного кэша.

Теперь необходимо упаковать шейдерный кэш в shadercache.pak, shadercachestartup.pak и shadersbin.pak, чтобы применять шейдерный кэш в релизной сборке игры.

Есть два способа.

1. Основной способ с использованием PakShaders.bat.

Взять из user shaders каталог cache с скомпилированным шейдерным кэшем, который был создан дистанционным компилятором шейдерных комбинаций (Remote Shader Compiler), и запаковать его содержимое с помощью скрипта PakShaders.bat, который активирует запаковщик 7za.exe, в результате создающий shadercache.pak, shadercachestartup.pak и shadersbin.pak. Полученные паки необходимо будет разместить в engine .

Читать еще:  Не открывается съемный жесткий диск что делать

Для начала необходимо скопировать из Tools PakShaders.bat и 7za.exe в каталог проекта/сборки игры Tools .

Для запуска PakShaders.bat потребуется создать bat -файл , который запустит PakShaders.bat . Н апрямую его запускать нельзя , т акова особенность работы скрипта . В данном примере « з апускатор» назва н PakShadersStart.bat (название не принципиально) , его необходимо разместить в корне проекта/сборки игры , иначе PakShaders.bat сработает некорректно. Суть в том, что PakShadersStart.bat как бы обозначит корень проекта/сборки игры, от которого будет вестись работа скрипта PakShaders.bat .

Пример расположения PakShadersStart.bat:

С:Programs The Cursed Forest PakShadersStart.bat

Пример содержимого PakShadersStart.bat:

«С:Programs The Cursed Forest Tools PakShaders.bat» d3d11

d3d11 — это каталог шейдерного кэша под DX11, который находится в user shaders cache . Для OGL будет GL4 .

Примечание: Пути в bat -файле регистрозависимые!

Примечание: Путь писать полностью и в кавычках! Кавычки для корректного чтения интерпретатором.

Примечание: При выполнении можно столкнуться с ограничением Windows на количество символов в путях и именах. В этом случае придётся копировать каталоги user shaders и Tools в каталог ближе к корню раздела.

Пример: C: PakShaders user shaders и C: PakShaders Tools

После описанных манипуляций запустить PakShaders Start .bat.

Должно появиться окно командной строки:

По завершению в корне проекта/сборки игры появятся shadercache.pak, shadercachestartup.pak и shadersbin.pak, которые необходимо поместить в engine с заменой, если ранее использовались стандартные наборы шейдерного кэша.

2. Альтернативный способ с использованием ShaderCacheGen.exe.

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

По данным из списка шейдерных комбинаций, который был создан дистанционным компилятором шейдерных комбинаций (Remote Shader Compiler), при помощи binwin_x64ShaderCacheGen.exe перекомпилировать g lobal shader cache, который будет упакован в shadercache.pak, shadercachestartup.pak и shadersbin.pak с использованием ToolsPakShaders.bat и Tools7za.exe .

Для компилирования g lobal shader cache понадобится список скомпилированных комбинаций шейдеров: ToolsRemoteShaderCompiler Assets ShaderList_PC.txt

ShaderList_PC.txt — это список комбинаций шейдеров под DX11 . Для OGL файл будет называться ShaderList_GL4.txt.

ShaderList_PC.txt нужно скопировать в use r shaders и переименовать в shaderlist.txt.

Для удобства компиляции файлов для shadercache.pak, shadercachestartup.pak и shadersbin.pak сделать bat- файл с командой binwin_x64ShaderCacheGen.exe -noprompt -anygpu /PrecacheShaderList

Примечание: bat- файл должен находиться в корне проекта/игры!

Примечание: Использовать абсолютный (полный) путь и заключить его в кавычки! Кавычки нужны для корректного чтения интерпретатором.

Примечание: Пути в bat -файле регистрозависимые!

Пример: “ С:Programs The Cursed Forest binwin_x64ShaderCacheGen.exe ” -noprompt -anygpu /PrecacheShaderLis t

П римечание: дистанционный компилятор шейдеров ToolsRemoteShaderCompiler CrySCompileServer.exe должен быть включен!

Перед компиляцией комбинаций шейдеров через дистанционный компилятор шейдеров (Remote Shader Compiler) необходимо удалить старые паки с шейдерами из директории проекта/сборки игры, кроме shaders.pak:

Запустить созданный bat- файл. Должна начаться компиляция.

Некоторые шейдеры могут быть не скомпилированы, чтобы убедиться, что всё нормально необходимо использовать r_displayinfo=2 и смотреть значение параметра промахов Global Cache Misses (GCM).

Файл ShadersShaderCacheMisses.txt должен быть пустой, что укажет на отсутствие промахов шейдеров = все шейдеры были взяты из шейдерного кэша и нет объектов, к которым не было загружено шейдера.

Бывает, что промахи есть, но не очевидно, как это устранить. Есть вероятность, что это очень незначительная комбинация и всё будет нормально без неё.

Тесты удвоения объёма кеша L3 процессора

Зачем нужен кэш и как он влияет на производительность?

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

Кэши L2 и L3 позволяют получать процессору данные максимально быстро. В современных моделях задержки достигают единиц наносекунд. Что, в прочим, тоже для процессора довольно долго. Но современные архитектуры процессоров на подобные задержки и рассчитаны. Естественно процессор не будет пропускать по несколько тактов работы ожидая данные из кеша L3. Для того чтобы такое не случалось внутри процессорного конвейера организовываются очереди микроопераций, в которых они и выдерживаются до тех пор пока необходимые данные не будут доступны для использования уже в регистровой памяти процессора.

Но если так случилось, что микрооперация попала в конвейер, а данные для её выполнения расположены не в каком-то из кэшей, а в оперативной памяти (или вообще в постоянной памяти), то процессору ничего не остаётся как пропустить эту микрооперацию, оставив её в очереди, и выполнять следующие за ней мирооперации. И называется это «мероприятие» промах в кэш (Cache Miss).

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

И естественно, что чем больше объём кэш памяти, тем реже будут происходить промахи в кэш, а значит реже будут простои, что в свою очередь приведёт к росту производительности в реальных задачах.

Насколько большая разница от изменения объёма?

И встаёт закономерный вопрос: «На сколько же велико влияние?».

Ответ на него, к сожалению, однозначным быть не может, так как всё зависит от конкретного приложения. Если его данные и все создаваемые им результаты помещаются в кэш, то последующее увеличение размера кэша вообще не приведёт к росту производительности. А если приложение постоянно обращается к совершенно разным участкам памяти, плохо оптимизировано под использование только что созданных процессором результатов, которые только-только были записаны в кэш, то разница от увеличения объёма может быть несколько крат.

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

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

Где рыжая линия показывает динамику изменения соотношений цены/производительности от увеличения объёма кэша. До определённого объёма — увеличение кэша приводит к значительному росту производительности так-как снижает частоту критичных состояний процессора когда он простаивает от промахов в кэш. Но при дальнейшем росте объёма всё меньше задач будут выполняться со значительными потерями в производительности, при дальнейшем росте стоимости процессора из-за увеличения кэш памяти.

Как измерить разницу от объёма?

И перейдём уже к практической области решения данного вопроса.

Для того чтобы понять разницу необходима некая конфигурация систем в которых отличия ограничиваются только объёмом кэш памяти.

В нашем случае это процессоры i7 7700k и i9 9900k. В последнем отключено 4 ядра из восьми (кэш память при этом не отключается).

В данном случае могла бы быть проблема связанная с программными исправлениями аппаратных уязвимостей более новых процессоров. Решена она запуском процессора i9 9900k на материнской плате ASUS Z170i Pro Gaming с BIOS версией 2002. К моменту выхода прошивки этой материнской платы об аппаратных уязвимостях сведений ещё не было и исправления их в тестовых системах — нет.

Про то как установить процессоры 8 и 9 поколений на платы для 6 и 7 поколений процессоров можете посмотреть тут.

Кроме процессора важно выбрать оперативную память. Я решил взять некие средние для DDR4 показатели. Частоту 3600 МГц с таймингами 17-18-18-38 CR2. Все субтайминги материнская плата выставляла автоматически.

Для игр так же стоит упомянуть о видеокарте: Gainward GeForce RTX 2070 Phoenix с небольшим заводским разгоном.

Обзор видеокарты можно посмотреть тут.

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

Результаты

Для начала проведём тест который покажет, что объём кэша действительно разный.

  • Тест кэша и памяти в Sandra

Тест задержек кэша и памяти позволяет увидеть переходы к разным уровням кэша и на оперативную память по увеличению задержек. График отлично показывает разницу в объёме кэша L3 по смещению долгих задержек от оперативной памяти (график логарифмический, поэтому двукратная разница в объёме выглядит не двукратной на глаз).

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

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

В однопоточном тесте CPU-z разницы от увеличения объёма кеша L3 — нет. В многопоточном разница — 3%

В Cinebench R15 разница 0,4% (незначительно превышает погрешности теста).

Тесты которые слабо реагируют на разгон памяти слабо реагируют и на увеличение объёма кэш памяти.

Далее рассмотрим блок тестов, в которых бенчмарки зависимые от частоты и задержек памяти.

Win-rar. Прирост производительности — 35%. Стоит отметить, что встроенный бенчмарк не отражает реальный прирост производительности архиватора.

7-Zip. Прирост 4,5%.

CPU тест 3D Mark Time Spy. Прирост 3,7%

  • Все бенчмарки

Выводы по бэнчмаркам

В идеальных задачах максимально оптимизированных для процессора и работы с памятью прирост находится в пределах 0-2%.

Для задач имеющий меньшую оптимизацию или связанных с работой с данными прирост от увеличения объёма кэш памяти составил от 3,7 до 35%.

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

Far Cry 5

Время кадра Плотность вероятности Распределение вероятности

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

Ссылка на основную публикацию
Статьи c упоминанием слов:

Adblock
detector