Что такое gfx driver

Обновлено: 30.06.2024

О программе
Набор драйверов AMD Chipset Drivers предназначен для правильной работы чипсета, SATA контроллера и всех других компонентов материнских плат, построенных на базе логики AMD
Что нового

Новое в версии 3.09.01.140 (13.09.2021):

Изменения:

Известные проблемы:

Новое в версии 2.17.25.506 (02.06.2021):

Исправлены проблемы:

  • Исправлена ошибка №1316 при обновлении драйвера.

Известные проблемы:

  • Для систем Windows с языковыми пакетами, отличными от английского, требуется ручная перезагрузка системы.
  • Всплывающее окно установщика Windows может появиться во время установки.
  • Журнал процесса деинсталляции не мог быть создан в автоматическом режиме.

Новое в версии 2.04.28.626 (Windows 7, 64-bit):

Системные требования

AMD Ryzen Chipset Drivers 2.10.13.408

  • Windows 10 (64-bit)
    • AMD TRX40
    • AMD X570 Chipset
    • AMD X470 Chipset
    • AMD X399 Chipset
    • AMD X370 Chipset
    • AMD B550 Chipset
    • AMD B450 Chipset
    • AMD B350 Chipset
    • AMD A320 Chipset
    • 1st/2nd/3rd Gen AMD Ryzen Threadripper Processors
    • 3rd Gen AMD Ryzen Desktop Processors
    • AMD Ryzen Desktop Processors with Radeon Graphics
    • AMD Ryzen Mobile Processors with Radeon Graphics
    • 1st/2nd Gen AMD Ryzen Desktop Processors
    • 2nd Gen AMD Ryzen Desktop Processors
    • 7th Gen AMD A-Series Processor

    AMD Ryzen Chipset Drivers 2.04.28.626

    • Windows 7 (64-bit)
      • 1st/2nd Gen AMD Ryzen Desktop Processors
      • 2nd Gen AMD Ryzen Desktop Processors
      • 7th Gen AMD A-Series Processor
      • AMD X470 Chipset
      • AMD B450 Chipset
      • AMD X370 Chipset
      • AMD B350 Chipset
      • AMD A320 Chipset

      AMD Chipset Drivers 18.10.0830

      Полезные ссылки
      Подробное описание

      AMD Chipset Drivers - включает все необходимые драйвера и компоненты для правильной работы операционной системы и программного обеспечения на компьютерах и ноутбуках, собранных на базе материнских плат с набором чипов AMD.

      Установка новейшей версии драйвера необходима для правильной работы всех компонентов компьютера, таких как контроллеры PCI Express, SATA и USB, а также для правильного управления питанием и энергосбережением.

      Новейший драйвер AMD Chipset Drivers включает следующие компоненты:

      Для Windows 10:

      • AMD Ryzen Power Plan - профиль энергопотребления
      • AMD I2C Driver - драйвер шины связи
      • AMD UART Driver - драйвер протокола передачи данных
      • AMD GPIO2 Driver - драйвер интерфейса ввода/вывода
      • PT GPIO Driver - драйвер интерфейса ввода/вывода
      • AMD AS4 ACPI Driver - драйвер интерфейса AS4 ACPI
      • AMD SFH Driver - драйвер контроллера SFH
      • AMD SFH I2C Driver - драйвер контроллера SFH I2C

      Для Windows 10/7:

      • AMD PCI Device Driver - драйвер контроллера PCI
      • AMD PSP Driver - драйвер подсистемы безопасности AMD
      • AMD IOV Driver - драйвер виртуализации ввода-вывода
      • AMD USB Filter Driver - драйвер фильтра USB устройств
      • AMD CIR Driver - драйвер параметра CIR
      • AMD MicroPEP Driver - драйвер устройства MicroPEP
      • AMD SMBUS Driver - драйвер шины системного управления

      Для Windows 7:

      • AMD SATA Driver - драйвер SATA контроллера
      • AMD USB Driver for Hudson - драйвер контроллера USB
      • AMD USB 3.0 Driver for ZP - драйвер контроллера USB 3.0
      • AMD USB 3.1 Driver - драйвер контроллера USB 3.1
      • PT USB 3.1 Driver - драйвер контроллера USB 3.1

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

      Intel Graphics Drivers

      О программе
      Intel Graphics Drivers – пакет драйверов и программного обеспечения, необходимых для правильной работы графических процессоров Intel и обеспечения высокой производительности в играх и программах
      Что нового

      Новое в версии 30.0.100.9894 Beta :

      Новое в версии 30.0.100.9862 Beta / 30.0.100.9864 DCH :

      Новое в версии 30.0.100.9805 DCH (11.08.2021):

      Новое в версии 27.20.100.9466 DCH (16.04.2021):

      Новое в версии 15.36.41.5180 (16.04.2021):

      Новое в версии 15.40.48.5171 (05.02.2020):

      Системные требования

      Подробную информацию о поддерживаемом оборудовании и доступных технологиях, смотрите в примечаниях в выпускам, ссылки на которые находятся в разделе "Что нового".

      Версия 30.0

      Поддерживаемые графические процессоры:

      • Windows 11, Windows 10 редакций 1709 и выше (64-bit)

      Версия 15.45

      Поддерживаемые графические процессоры:

      • 6-е поколение процессоров Intel Core, Intel Core M и другие на базе Pentium с графикой Intel Iris Graphics 540, Intel Iris Graphics 550, Intel Iris Pro Graphics 580, и Intel HD Graphics 510, 515, 520, 530.
      • Windows 8.1 (32-bit и 64-bit)
      • Windows 7 (32-bit и 64-bit)

      Версия 15.40

      • 5-е поколение процессоров Intel Core и другие на базе Pentium/Celeron, на операционных системах Windows 10 (64-bit), Windows 8.1 / 7 (32-bit и 64-bit).
      • 4-е поколение процессоров Intel Core и другие на базе Pentium/Celeron, на операционных системах Windows 10 (32-bit и 64-bit).
      • Процессоры семейства Braswell/CherryTrail, на операционных системах Windows 10 / 8.1 / 7 (32-bit и 64-bit).
      Полезные ссылки
      Подробное описание

      Intel Graphics Drivers – это обязательный к установке пакет программного обеспечения, необходимый для полноценного функционирования графических процессоров Intel. Несмотря на то, что операционная система применяет универсальный драйвер для использования основных функции оборудования, установка полных и обновлённых версий драйверов и необходимого программного обеспечения Intel, позволяет добиться наивысшей производительности и стабильности, реализации всех доступных функций и технологий, а также свести к минимуму проблемы совместимости и различные ошибки в работе системы.

      Состав установочного пакета драйверов Intel Graphics

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

      Intel Media SDK Runtime - пакет разработки, который включает в себя инструменты и компоненты, помогающие программистам создавать приложения с поддержкой аппаратного ускорения кодирования, декодирования и обработки видео.

      Intel OpenCL Driver - пакеты драйверов и библиотек, для разработки приложений с расширенной функциональностью IDE, средствами отладки и анализа, и другими инструментами.

      Vulkan Runtime Installer - набор библиотек для повышенной производительности в играх и программах, использующих API Vulkan.

      Intel Graphics Command Center (IGCC) - это простое и удобное в использования программное обеспечение с современным дизайном, для оптимизации производительности и управления различными настройками графики.

      Центр управления графикой Intel

      Начиная с версии драйверов DCH для Windows 10, Центр управления графикой Intel получил крупное обновление и различные улучшения. Он больше не будет включён в состав установочных файлов драйверов, но будет автоматически загружаться и устанавливаться при первом подключении к интернету. Также, программу можно установить самостоятельно из магазина Microsoft Store.

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

      Intel® Graphics Technology. Часть I: почти Gran Turismo


      Кроме регистров, графике доступен свой L3 кэш (256 KB на каждые ½ «слоя»), а также LLC (Last Level Cache), который является L3 процессорным кэшем и, таким образом, общим для CPU и GPU. С точки зрения вычислений на GPU, кэшей L1 и L2 нет. Только в самой мощной конфигурации GT3e доступно ещё 128 MB кэша eDRAM. Он находится в одном корпусе с процессорным компонентом, но не является частью кристалла Haswell, и играет важную роль в увеличении производительности встроенной графики, почти ликвидируя зависимость от оперативной памяти компьютера (DRAM), часть которой так же может быть использована в качестве видеопамяти.

      Далеко не все версии процессоров имеют ту самую интегрированную графику. Серверные модели предпочитают иметь значительно больше вычислительных ядер вместо графики, поэтому случаи, в которых возможно применение Graphics Technology, существенно сужаются. Я наконец дождался лэптопа с Haswell’ом и встроенной в процессор графикой Intel HD Graphics 4400, а, значит, можно поиграться с Intel Graphics Technology, которая поддерживается на 64 битных Linux системах, а так же на 32 и 64 битных Windows системах.

      • Intel Xeon Processor E3-1285 v3 and E3-1285L v3 (Intel C226 Chipset) с Intel HD Graphics P4700
      • 4е поколение Intel Core процессоров с Intel Iris Pro Graphics, Intel Iris Graphics или Intel HD Graphics 4200+ Series
      • 3е поколение Intel Core процессоров с Intel HD Graphics 4000/2500

      С точки зрения кода, ничего экстраординарного я не заметил. Да, появились какие-то прагмы перед циклами cilk_for, вроде таких:


      Об этом мы поговорим подробно в следующем посте, а пока попробуем собрать сэмпл с опцией /Qoffload. Вроде бы всё скомпилировалось, но ошибка о том, что линкер (ld.exe) не может быть найден, меня немного приостановила. Оказалось, я упустил один важный момент и не всё так тривиально. Пришлось покопаться в документации.

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


      Компилятор не умеет генерировать код, который сразу может выполняться на графике. Он создает IR (Intermediate Representation) код под vISA (Virtual Instruction Set Architecture) архитектуру. А тот в свою очередь может выполняться (конвертироваться в рантайме) на графике с помощью JIT’тера, поставляемого в установочном пакете с драйверами для Intel HD Graphics.

      При компиляции нашего кода с использование оффлоада для Graphics Technology, генерится объектник, в который «вшита» часть, выполняющаяся на графическом ядре. Этот общий файл называется fat. При линковке вот таких вот «толстячков» (fat объектников), код, выполняющийся на графике, будет в секции, встроенной в бинарник на хосте, называемой .gfxobj (для случая Windows).
      Вот тут то становится понятно, почему не находился линкер. У компилятора Intel нет и не было своего линкера, причем что на Linux, что на Windows. А здесь в один файл нужно «зашить» объектники в разных форматах. Простой линкер от Microsoft делать этого не умеет, поэтому нужно поставить специальную версию binutils (2.24.51.20131210), доступную здесь, а потом и прописать пусть к тому самому ld.exe (в моем случае C:\Program Files (x86)\Binutils for MinGW (64 bit)\bin) в PATH.
      После установки всего необходимого, я в итоге собрал тестовый проект на Windows и получил следующее:

      Нужный объектник для выполнения на графике можно извлечь из fat объектника с помощью специального инструмента (offload_extract). Если в нашей консоли выставлено окружение для запуска компилятора Intel, сделать это весьма просто:

      В результате в папочке можно найти отдельный объектник с приставкой GFX в конце, в моем случае — matmultGFX.o. Он, кстати, уже ни разу не в PE формат, а в ELF’е.

      Кстати, если оффлоад невозможен и графическое ядро недоступно во время запуска приложения, выполнение происходит на хосте (CPU). Это достигается с помощью средств компилятора и оффлоад рантайма.
      С тем, как всё должно работать мы разобрались. Дальше будем говорить о том, что доступно разработчику и как написать код, который в итоге будет работать на графике.
      Информации оказалось так много, что в рамки одного поста всё никак не помещается, поэтому, как говорится, «продолжение следует…».

      Intel® Graphics Technology. Часть II: «выгружаем» вычисления на графику


      Продолжаем начатый разговор о Intel® Graphics Technology, а именно о том, что у нас есть в распоряжении с точки зрения написания кода: прагмы offload и offload_attribute для оффлоадинга, атрибуты target(gfx) и target(gfx_kernel), макросы __GFX__ и __INTEL_OFFLOAD, интринсики и набор API функций для асинхронного оффлоада. Это всё, что нужно нам для счастья. Чуть было не забыл: конечно, нам нужен компилятор от Intel и магическая опция /Qoffload.

      Но обо всё по порядку. Одна из основных идей – это относительно легкая модификация существующего кода, выполняемого на CPU для его выполнения на интегрированной в процессор графике.

      Легче всего это показать на простом примере суммирования двух массивов:


      С помощью технологии Intel® Cilk™ Plus мы можем легко сделать его параллельным, заменив цикл for на cilk_for:


      Или создаем ядро для асинхронного выполнения, используя спецификатор __declspec(target(gfx_kernel)) перед функцией:


      Кстати, везде фигурирует набор букв GFX, который и должен наводить нас на мысль, что работаем мы именно с интегрированной графикой (GFX – Graphics), а не с GPU, под которой чаще понимают дискретную графику.

      Как вы уже поняли, у процедуры есть ряд особенностей. Ну, во-первых, всё работает только с циклам cilk_for. Понятно, что для хорошей работы должна быть параллельная версия нашего кода, но пока поддерживается именно механизм для работы с циклами из Cilk’а, то есть тот же OpenMP идет мимо кассы. Нужно помнить и о том, что графика не очень работает с 64 битными «флотами» и целыми – особенности «железа», так что ждать высокой производительности с такими операциями не приходится.

      Существуют два основных режима для вычислений на графике: синхронный и асинхронный. Для реализации первого используются директивы компилятора, а для второго – набор API функций, при этом для осуществления оффлоада необходимо будет объявленную таким образом функцию (ядро) «положить» в очередь на выполнение.

      • if (condition) – код будет выполняться только на графике, если условие истинно
      • in|out|inout|pin(variable_list: length(length_variable_in_elements))
        in, out, или inout – указываем, какие переменные копируем между CPU и графикой
      • pin – выставляем переменные, общие для CPU и графики. В этом случае, копирования данных не происходит, а используемая память не может свопиться.
      • length – необходимая вещь при работе с указателями. Нужно задать размер данных, которые нужно копировать в/из памяти графики, или, которые нужно делить с CPU. Задается в виде числа элементов типа указателя. Для указателя на массив это число соответствующих элементов массива.

      В нашем примере суммирования двух массивов, мы как раз используем параметр pin(a, b, c:length(N)):


      То есть массивы a и b не копируются в память графики, а остаются доступными в общей памяти, при этом соответствующая страница не свопится, пока мы не закончим работу.
      Кстати, для игнорирования прагм используется опция /Qoffload-. Ну это если вдруг нам резко надоест оффлоад. Кстати, ifdef’ы никто не отменял, и подобный прием всё ещё весьма актуален:


      Асинхронный режим
      Рассмотрим теперь другой режим оффлоада, который основывается на использовании API функций. У графики имеется своя очередь на выполнение, и всё что нам необходимо – это создать ядра (gfx_kernel) и положить их в эту очередь. Ядро можно создать с помощью спецификатора __declspec(target(gfx_kernel)) перед функцией. При этом, когда поток на хосте посылает ядро на выполнение в очередь, он продолжает выполнение. Тем не менее, существует возможность дождаться окончания выполнения на графике с помощью функции _GFX_wait().

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

      Кроме того, в асинхронном режиме не предусмотрена генерация кода как для хоста, так и для графики. Поэтому придется позаботится о реализации кода только для хоста самим.

      Вот как выглядит код для вычисления суммы массивов в асинхронном режиме (асинхронный вариант кода для vec_add был представлен выше):


      Итак, мы объявляем и инициализируем 4 массива. С помощью функции _GFX_share явно говорим, что эту память (начальный адрес и длина в байтах задаются параметрами функции) нужно пиннить, то есть будем использовать память общую для CPU и графики. После этого кладем в очередь нужную функцию vec_add, которая определена с помощью __declspec(target(gfx_kernel)). В ней, как и всегда, используется цикл cilk_for. Поток на хосте кладёт второй просчёт функции vec_add с новыми параметрами в очередь без ожидания выполнения первой. С помощью _GFX_wait мы ожидаем выполнения всех ядер в очереди. И в конце явно останавливаем пиннинг памяти с помощью _GFX_unshare.

      Не забываем, что для использования API функций нам понадобится заголовочный файл gfx_rt.h. Кроме того, для использования cilk_for нужно подключить cilk/cilk.h.
      Интересный момент заключается в том, что по умолчанию установленный компилятор найти gfx_rt.h не смог – пришлось прописать путь к его папочке (C:\Program Files (x86)\Intel\Composer XE 2015\compiler\include\gfx в моём случае) ручками в настройках проекта.

      Ещё я нашёл одну интересную опцию, о которой не сказал в предыдущем посте, когда говорил о генерации кода компилятором. Так вот, если мы заранее знаем, на какой «железке» будем работать, то можем указать это компилятору явно с помощью опции /Qgpu-arch. Пока варианта всего два: /Qgpu-arch:ivybridge или /Qgpu-arch:haswell. В реультате линкер вызовет компилятор для трансляции кода из vISA архитектуры в нужную нам, и мы сэкономим на JIT’тинге.

      И напоследок важное замечание про работу оффлоада на Windows 7 (и DirectX 9). Критично, чтобы дисплей был активный, иначе ничего не заработает. В Windows 8 такого ограничения нет.

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

      Читайте также: