Драйвер amd gpio что это

AMD Chipset Drivers

О программе

Что нового

Новое в версии 3.10.08.506 (21.10.2021):

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

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

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

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

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

AMD Ryzen Chipset Drivers 2.10.13.408

AMD Ryzen Chipset Drivers 2.04.28.626

AMD Chipset Drivers 18.10.0830

Полезные ссылки

Подробное описание

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

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

Для Windows 11 и 10:

Для Windows 11, 10 и 7:

Для Windows 7:

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

Источник

Драйвер виртуальных GPIO с контроллером прерываний на базе QEMU ivshmem для Linux

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

Основываясь на собственном скромном опыте, могу сказать, что прерывания далеко не самая освященная тема в сообществе Linux. Из-за своих особенностей, а так же сильной привязки к аппаратной части, все обучающие материалы посвященные прерываниям лишены реального и легко воспроизводимого примера. Данный факт мешает пониманию того, что очень часто прерывания и GPIO неразделимы, особенно в области встраиваемого Linux. Многие начинают верить, что GPIO это очень простая и скучная вещь (которая кстати и стала таковой благодаря подсистеме sysfs).

Даже в примере приведенном в LDD3 (драйвер snull) прерывания эмитируются явным вызовом функции парного устройства. Так же имеются примеры в курсах USFCA (http://cs.usfca.edu/

cruse/cs686s08/), но они используют чужое прерывание, тесно связаны с архитектурой x86 и сильно устарели.

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

ivshmem — разделяемая память Inter-VM

Разработано для совместного использования разделяемой памяти (выделенной на хост-платформе через механизм POSIX shared memory API) множественными процессами QEMU с различными гостевыми платформами. Для того чтобы все гостевые платформы имели доступ к области разделяемой памяти, ivshmem моделирует PCI устройство предоставляя доступ к памяти как PCI BAR.

и проанализировал быстродействие в целом.

В настоящей момент, официально, сопровождение ivshmem никто не осуществляет, тем не менее большой вклад в развитие ivshmem вносят сотрудники Red Hat.

ivshmem может послужить основой для симуляции и отладки многих классов устройств.
В данной статье мы рассматриваем виртуальную pci плату ввода/вывода общего назначения (general-purpose input/output, GPIO), которая так же является источником прерываний, и соответствующий драйвер с предоставлением доступа и управления посредством механизма sysfs.

Для разработки и тестирования использовалась виртуальная плата qemu versatilepb (system ARM).

g>> — команды или вывод выполняемые на гостевой системе.
h>> — на основной.

Пример и оригинальный код

Для начала продемонстрируем оригинальный код, основанный на оригинальном коде ( https://github.com/henning-schild/ivshmem-guest-code ), и модифицированном, в последствии, Siro Mugabi.

В принципе этого вполне достаточно для эмуляции GPIO уже в таком виде. И во многих случаях так и поступали, когда достаточно простого состояния входа или записи в выход, использование sysfs и прерываний предполагают небольшую надстройку на I/O mem.

Реализация

Заметим, что /dev/ivshmem0 и ne_ivshmem_shm_guest_usr.c нам более не нужны, вся работа с устройством со стороны гостевой машины из пространства пользователя (user-space) будет осуществляться средствами интерфейса sysfs.

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

Во-первых все входа/выхода gpio разделены на порты, как правило по 8, 16, 32 входа. Каждый порт имеет, как минимум, регистр состояния входов (GPIO_DATA), регистр направления, если переключение in/out поддерживается (GPIO_OUTPUT). Далее (если есть поддержка в самом устройстве), регистр состояния прерываний, регистры прерывания по переднему фронту (rising) и заднему фронту (falling) и по уровню (high и low). Аппаратное прерывание, поставляемое главным контроллером прерываний, как правило, одно на весь порт и делится между всеми входами порта.

Примеры существующих реализаций с комментариями

Sitara am335x

более известна в составе платы beaglebone

Разработчик: Texas Instruments
Документация: AM335x Sitara Processors Technical Reference Manual (page 4865)
Соответствующий ему драйвер gpio: linux/drivers/gpio/gpio-omap.c
Соответствующий заголовок: linux/include/linux/platform_data/gpio-omap.h
Количество входов/выходов: 128 (4 gpio порта — по 32 контакта каждый)

Разработчик:	Advanced Micro Devices (США)
Лицензия:	Бесплатно
Версия:	3.10.08.506 (Windows 10/11, 64-bit) / 2.17.25.506 (Windows 7, 64-bit) / 18.10.0830 (32-bit)
Обновлено:	2021-10-21
Системы:	Windows 11 / 10 / 8.1 / 8 / 7 / Vista / XP (32/64-bit)
Интерфейс:	русский / английский
Рейтинг:
Ваша оценка:

Примечание: GPIO_IRQSTATUS_N также используется для IRQ ACK. Управление дребезгом, а так же питанием выходит за рамки данной статьи.

ep9301

Разработчик: Cirrus Logic
Документация: EP9301 User’s Guide (page 523)
Соответствующий ему драйвер gpio: linux/drivers/gpio/gpio-ep93xx.c
Соответствующий заголовок: linux/arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h
Количество входов/выходов: 56 (7 портов gpio — по 8 контактов каждый)

Примечание:
Из них для доступны 7 портов по 8, 8, 1, 2, 3, 2, 4 входов/выходов причем регистрами прерываний обладают только первый, второй и пятый порты.
В таблице рассмотрен только порт A.
Одной из особенностей ep9301, является то что тип прерываний both на аппаратном уровне не поддерживается, в драйвере происходит переключение в момент срабатывания прерывания. Другая интересная особенность — на порту F каждый контакт имеет свое собственное прерывание.

Bt848

Последний пример: pci плата Bt848, с gpio.

Разработчик: Intel
Документация: Bt848/848A/849A (page 68)
Соответствующий драйвер gpio: linux/drivers/gpio/gpio-bt8xx.c
Соответствующий заголовок: linux/drivers/media/pci/bt8xx/bt848.h
Количество входов/выходов: 24

Bt848 является платой видеозахвата.

Поддержки прерываний нет. Всего два регистра — состояние и настройка in/out.

Размечаем в памяти наше устройство

Для начала выделим место под данные и управление состоянием.

Пусть устройство обладает 8 входами/выходами общего назначения, тогда:

Краткая справка по интерфейсу gpio

Состояние выхода при переключении

Необходимо отметить параметр int value в функции direction_output, которая обслуживает файл /sys/class/gpio/gpioN/direction, принимающий значение не только “in”/”out”, но так же и “high”/“low”, значения которых передаются как параметр value (этот простой факт, по какой-то причине, редко упоминается в руководствах для начинающих).

Динамическое присвоение int base и наследие ARCH_NR_GPIOS

Исторически, количество GPIO в ядре было ограничено параметром ARCH_NR_GPIOS, по умолчанию равном 256 и, впоследствии увеличенном до 512 (версия 3.18).

Его смысл достаточно прост, в ядре не может быть больше GPIO чем значение параметра, если планируемое количество было больше чем значение по умолчанию, он переопределялся в соответствующем заголовочном файле платформы.

Причиной такого поведения было определение таблицы описаний GPIO как статической и максимальная величина смещения для каждого порта была ограничена:

Порты GPIO и их смещения были жестко определены в файлах описывающих аппаратную часть конкретного SOC, например:

Начиная с версии 3.19 статический массив был заменен на динамические для каждого порта GPIO, выделяемого в фукнции gpiochip_add().

Тем не менее ARCH_NR_GPIOS все еще здесь (на момент версии 4.7) и используется для поиска смещения при динамическом присваивании base.

Определим следующие функции нашего драйвера

Задать соответствующий контакт как вход:

Чтение текущего состояния контакта:

Задать соответствующий контакт как выход:

Задать состояние выхода:

Функция регистрации нашего драйвера как устройства gpio_chip:

vgread и vgwrite это просто обертки для функций iowrite8 и ioread8:

Передача значения gpiobase в качестве параметра при динамической загрузки модуля

Загрузка и тестирования модуля

DATA выставлен, OUTPUTEN выставлен.

Добавляем прерывания

Разметка регистров прерываний и базовая обработка прерывания

Примечание: В виртуальном драйвере рассматриваются только EDGEDETECT_RISE и EDGEDETECT_FALL.

Добавляем следующие регистры:

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

irq_chip и концепция chained_interrupt

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

Вот почему часть драйвера GPIO отвечающего за прерывания использует irq_chip. Другими словами такой драйвер использует две подсистемы одновременно: gpio_chip и irq_chip.

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

High-Level Interrupt Service Routines (ISRs) — Выполняет всю необходимую работу по обслуживанию прерывания на драйвере устройства. Например, если прерывание используется для индикации доступных для чтения новых данных, работа ISR будет заключаться в копировании данных в соответствующее место.

Interrupt Flow Handling — Данная подсистема отвечает за особенности в реализации обработок прерываний, таких как срабатывание по уровню сигнала (level) или по фронту (edge).

Срабатывание по фронту (Edge-triggering) происходит при определении, что на линии произошло изменение потенциала. Срабатывание по уровню (Level-triggering), определяется как определенное значение потенциала, при этом изменение потенциала не играет роли.

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

Chip-Level Hardware Encapsulation — Используется для инкапсуляции особенностей реализации работы с аппаратной частью. Данную подсистему можно рассматривать как разновидность “драйвера устройства” для контроллеров прерываний.

Как мы видим ядро берет на себя управление обработкой цепочки прерывания и разницу в реализации типов (по фронту и по уровню), если предоставить соответствующую инфраструктуру.

IRQ Domains

Подсистема IRQ Domain появившееся в патче irq: add irq_domain translation infrastructure позволила отделить локальные для контроллера номера прерываний от номеров прерываний в ядре, предоставив общий массив номеров прерываний. Цитируя официальную документацию: «Сегодня номер IRQ, это просто номер».

До данного обновления аппаратные номера отображались на номерами ядра как 1:1, а каскадирование не поддерживалось. Под аппаратными номерами, понимается локальные для контроллера номера прерывания, которые в нашем случае совпадают с локальными номерами GPIO.

Поскольку наш вектор прерываний достаточно мал, и у нас точно нет интереса в «No map» отображении, наше отображение линейно, фактически номера сопоставляются 1:1 со смещением, разница со старым подходом состоит в том что за присвоение номеров irq и за вычисление смещения отвечает ядро, при этом гарантируется непрерывность выделяемого диапазона.

В каждую функцию интерфейса irq_chip передается указатель на структуру struct irq_data, где irq_data->irq это номер прерывания в ядре linux, a irq_data->hwirq это наш локальный номер прерывания в рамках драйвера. Так же в struct irq_data передается указатель на нашу структуру struct virtual_gpio, что неудивительно.

Связывание irq_chip и gpio_chip

Если бы мы ориентировались на более младшие версии ядра, нам пришлось бы воспользоваться функцией irq_domain_add_simple для отображения наших номер, но с версии 3.15 в патче gpio: add IRQ chip helpers in gpiolib patch нет необходимости напрямую использовать интерфейс IRQ Domain.

Поэтому вместо прямого использования интерфейса IRQ Domain и предоставления инфраструктуры для отображения локальных номеров на глобальные (.map() ops), мы воспользуемся функциями gpiochip_irqchip_add и gpiochip_set_chained_irqchip (зависят от параметра GPIOLIB_IRQCHIP Kconfig).

Прекрасным примером использования и простоты в применении, является драйвер gpio-pl061.

Привязываем наш irq_chip к уже существующему gpio_chip:

handle_edge_irq — это один из встроенных обработчиков потока, который берет на себя управление цепочкой прерывания по фронтам.

Примечание: прерывания по фронтам является наиболее распространенным. Главное отличие от прерываний по уровню заключается как раз в управлении цепочкой, прерывание по уровню маскируется в ядре сразу после получения.

Вызовом функции gpiochip_set_chained_irqchip мы сообщаем ядру, что наш irq_chip использует прерывание от PCI шины и наши прерывания каскадируются от pdev->irq.

Доработаем наш обработчик, чтобы он генерировал прерывания в зависимости от состояния VIRTUAL_GPIO_INT_ST:

irq_find_mapping — вспомогательная функция для трансляции локального номера входа в глобальный номер прерывания.

Собираем все вместе

Прежде всего, отметим, что интерфейс irq_chip нашего драйвера, выглядит следующим образом:

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

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

Маскирование и демаскирование производится записью соответствующего значения в регистр INTERRUPT_EN.

irq_type позволяет задать тип триггера — на текущий момент в ядре определены следующие типы:
IRQ_TYPE_NONE — тип не задан
IRQ_TYPE_EDGE_RISING — по переднему фронту
IRQ_TYPE_EDGE_FALLING — по заднему фронту
IRQ_TYPE_EDGE_BOTH — по переднему и заднему фронту
IRQ_TYPE_LEVEL_HIGH — по высокому уровню
IRQ_TYPE_LEVEL_LOW — по низкому уровню

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

Для тестирования передачи информации о прерываниях в user space, воспользуемся специально написанной утилитой vg_guest_client. Согласно документации по gpio_sysfs, “Если вы используете select для отслеживания событий, задайте файловый дескриптор (входа) в exceptfds”.

Подготавливаем входы к работе при помощи sysfs:

Примечание: gpio на подавляющем большинстве устройств по умолчанию инициализируются как входы.

Цепочка вызовов от нашего обработчика прерывания к уведомлению pselect:

Заключение

Данная статья подразумевалась мной, как базовая для материала, который сложно, или даже невозможно, представить без какого-либо общего вступления. Qemu в паре с ivshmem послужили отличным и понятным базисом для этой цели. Причиной выбора этой конкретной связки является наличие вменяемой документации и прозрачности использования.

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

Сам драйвер, несмотря на безусловную образовательную ценность, далек от идеала в контексте современного ядра. Для подобного простого драйвера стоит использовать generic-gpio драйвер, созданный, чтобы избежать похожего, повторяющегося кода для mmio gpio драйверов, использование которого, правда, не так очевидно. Обработку прерываний можно было бы сделать более элегантной, а значения смещений регистров лучше хранить в структуре драйвера.

Так же нельзя упускать из виду последние изменения в gpiolib — sysfs gpio теперь является устаревшей. Новый основанный на ioctl интерфейс для gpiolib на пути становления как новый стандарт для общения с GPIO. Но младшие версии еще долго будут использоваться, к тому же никто не собирается на данный момент убирать из ядра старый интерфейс. У меня например до сих пор есть устройства успешно работающие на версии ядра 2.6.34.

Источник

Как я драйвер AMD неделю побеждал

У меня была знатная попаболь от амдэшних дров. Ноутовская 6650м+интел.

При переключении графики(при запуске игор) 1 раз а 50 был черный экран, где спасением был только принудительное выключение.

Еще 1 на 100 случай ловил бсод при включении фильма на mpc или переключение сериалов(по порядку играет). Это притом, что мрс залочен на интеловскую.

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

Буду обновляться до 10, буду бить в бубен. покрещюсь ктулхе, вознесу жертву будде. может пройдет без косяков.

пс. проблема была на 7, 8, 8.1

Интел+амд даже звучит смешно. Обычно интел+нвидеа или амд.

Intel vs AMD

Наглядное сравнение превосходства нового интела 12900k на амд 5950x

TSMC: дефицит чипов создают искусственно

Увидел анонс новой системы от AMD, которую якобы готовили для XBOX, но что-то пошло не так.
Перейдя на сайт с официальной новостью увидел это!

Кто сомневается, загуглите стоковый кулер Интел. Даже наклейка того цвета.

Самые необычные процессоры

Core-B – Это неофициальное название, придуманное просто для удобства.

На самом деле это те же настольные процессоры Coffee Lake, только имеющие одно любопытное отличие – они имеют исполнение BGA, то есть распаиваются на плате, и формально относятся к мобильной линейке.

Всего имеется три процессора: Core i7-8700B, Core i5-8500B и Core i5-8400B. По своим параметрами они полностью идентичны настольным моделям с аналогичными индексами. Зачем тогда они нужны, ведь для ноутбуков их теплопакет слишком большой, а в декстопах можно использовать настольные процессоры?

Это семейство процессоров выглядело странным как на бумаге, так и в реальности. Причина — практически полная идентичность со старшими CPU для LGA 1151, но при этом процессорам Kaby Lake-X требовались дорогие системные платы.

3. Treadripper 2000WX

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

Они состояли из четырёх кристаллов,в каждом из которых физически было 8 ядер и двухканальный контроллер памяти, но так как сокет поддерживал работу памяти только в четыре канала DDR4, то в двух кристаллах контроллеры памяти были деактивированы, и в результате время доступа к памяти для ядер на разных кристаллах было разным.

Для корректной работы, программы должны были быть оптимизированы полд работу на данных камнях.

Этот процессор является представителем третьего поколения серверных процессоров EPYC, и его необычность заключается в том, что при наличии восьми ядер, он имеет 256mb кеша третьего уровня,

Это достигается тем, что в каждом из восьми чиплетов с ядрами и кешем, состоящем из восьми ядер 32mb кеша третьего уровня, деактивировано 7 ядер, в результате на каждый кристалл приходится одно ядро и 32mb кеша третьего уровня, в ryzen 7 5800x один полностью рабочий чиплет.

Эти мобильные процессоры сочетали вычислительные ядра Intel в самодостаточном кристалле и «подселяемую» за счёт использования кремниевого моста дискретную графическую подсистему Radeon RX Vega M с отдельной памятью типа HBM2.

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

Через несколько лет после выхода на рынок их продажи свернули.

Intel vs. AMD без кулера. 2001 год

Наверное, многие видели этот видос. У меня на тот момент даже диалапа не было

Как Intel, AMD и Nvidia обманывают покупателей ноутбуков

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

Однако выглядит — не значит является. Возьмем, например, десктопный сегмент. В нем Intel Core i7 отличаются от Core i9 меньшим числом ядер или потоков, и на деле между ними ощутимая разница в производительности.

А что же в ноутбуках?

А в ноутбуках что некоторые Core i7, что некоторые Core i9 могут иметь по 8 ядер и 16 потоков. В чем же между ними разница, спросите вы? В частоте: у Core i9 она на пару-тройку сотен мегагерц выше, что в теории должно добавить еще 10-15% производительности.

А на практике нередко бывает так, что в ноутбуках топовый Core i9 выступает на уровне и даже хуже Core i7. Почему так?

Всему виной очень жесткий теплопакет, который составляет по умолчанию 45 Вт.

Посудите сами — десктопный Core i9-9900K с частотой в 5 ГГц под нагрузкой может и 150 Вт выделять. Поэтому очевидно, что аналогичные по числу ядер мобильные Core i9, зажатые в 4 раза меньший теплопакет, реально под нагрузкой держат частоту в 3-3.5 ГГц. Так что не удивительно, что опять же аналогичные по числу ядер мобильные Core i7 с аналогичным теплопакетом в 45 Вт показывают тот же уровень производительности.

Бывает еще смешнее: так, теплопакет в 45 Вт — номинальный, и его можно двигать как в сторону уменьшения, так и в сторону увеличения. Поэтому Core i7 с условным теплопакетом в 60 Вт будет быстрее Core i9 с теплопакетом в 45 Вт.

Вот и получается, что красивое лого Core i9 на корпусе ноутбука может быть просто фикцией. Поэтому, выбирая себе лэптоп, внимательно изучайте его обзоры — вполне возможно, что логичным решением будет остановиться на Core i7 или даже Core i5, потому что реального прироста производительности от более старших версий CPU просто не будет.

Касается ли это AMD? Увы — теперь тоже да: если раньше мобильные Ryzen 4000 были четко разделены по числу ядер, то теперь новые Ryzen 5000 представляют собой мешанину линеек и ядер, как и у Intel.

Что еще хуже — компания решила мухлевать и с названием различных CPU.

Простой пример — есть 8-ядерный Ryzen 9 5900HX с частотой до 4.6 ГГц и теплопакетом в 45 Вт, и казалось бы больший по номеру модели Ryzen 9 5980HS с аналогичным числом ядер, частотой до 4.8 ГГц, но теплопакетом всего в 35 Вт.

В теории по названию старшим CPU является второй, а на деле под нагрузкой быстрее будет первый. Красный маркетинг в действии.

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

Видишь RTX 3080? Нет? И правильно, это RTX 3070

И, как вы уже догадались, Nvidia занимается таким же мухлежом. Хотя даже не таким — зеленые шуллерствуют куда сильнее синих и красных. Возьмем их новую линейку мобильных видеокарт на архитектуре Ampere, они же RTX 3000. У топа, RTX 3080, 6144 ядра CUDA. Но стоп, у десктопной ведь 8704? Вы все верно помните.

И, как понимаете, мобильная RTX 3080 в принципе не может быть на уровне десктопной — ее реальный уровень производительности оказывается ближе к RTX 3070 с 5888 ядрами CUDA.

Таким шагом Nvidia по сути перечеркнула весь свой труд последних четырех лет, когда она всеми силами доказывала, что мобильные видеокарты почти как десктопные, лишь чуть по частотам хуже. По сути так оно и было: что десктопные GTX 1000 и RTX 2000, что их мобильные собратья базировались на одинаковых GPU.

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

Дальше — хуже. В предыдущих линейках мобильных видеокарт Nvidia были версии Max-P и Max-Q. Первые выделялись максимально высоким теплопакетом и частотами, вторые наоборот были максимально урезанными, дабы их можно было ставить в тонкие ноутбуки и называть их игровыми=). То, что при этом какая-нибудь RTX 2080 Max-Q могла оказаться медленнее RTX 2060 Max-P мы уже не раз говорили, и вы наверное к этому уже привыкли.

Опять же, это была не идеальная схема, но все же она работала: вы могли бросить взгляд на характеристики лэптопа и понять, с каким уровнем производительности вы имеете дело. Сюрприз — в линейке RTX 3000 разделений на Max-Q и Max-P больше нет.

Конечно, это вызвало негодование покупателей, которые приобрели лэптопы с RTX 3080 и вдруг оказалось, что она там зарезана дальше некуда и выдает производительность на уровне RTX 3060. И компания Nvidia решила «помочь» пользователям с выбором — теперь производители ноутбуков рядом с используемой видеокартой пишут ее теплопакет.

Вот видите вы RTX 3070 с 110 ваттами. Это какая версия? Ближе к топу? Или наоборот урезанная? Сказать сложно, не правда ли?

Нужно лезть на сайт Nvidia, искать спецификации мобильной RTX 3070 и смотреть на возможные для нее теплопакеты. Очень удобно, не правда ли?

Ах да, всего мобильных RTX 3000 может существовать 28 штук. Хуанг желает вам удачи в выборе.

В итоге мы получаем, что мобильные RTX 3000 отличаются от десктопных по числу CUDA-ядер и памяти, да еще и версий там пруд пруди. Поэтому единственный способ не ошибиться — внимательно изучать обзоры заинтересовавшего вас лэптопа, дабы понять конкретно его уровень производительности в играх.

Если в сегменте десктопных процессоров и видеокарт все максимально просто, и различные версии той же RTX 3060 отличаются по производительности буквально на пару процентов, то вот в ноутбуках творится полнейший адЪ.

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

Так что обзоры, обзоры и еще раз обзоры — ваши лучшие друзья в подборе игрового ноутбука. Спецификации лэптопов сейчас врут вам как никогда, не полагайтесь на них.

Компания Microsoft обвалила акции Intel

Американский IT-гигант Microsoft планирует выпускать свои процессоры. Из-за этой новость акции Intel обвалились.

Как передает агентство Bloomberg, компания собирается как Apple наладить выпуск процессоров собственной разработки. Это позволит компании сэкономить на закупке компонентов для своих устройств, а также ослабить зависимость от Intel, AMD и Qualcomm.

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

Сейчас компания активно набирает в новую команду бывших сотрудников Intel, AMD, Nvidia и Qualcomm. Cовременный сервис Azure строится на процессорах семейства Intel Xeon. В ноутбуках и планшетах Surface применяются как процессоры Intel, так и чипы Snapdragon, созданные Microsoft в сотрудничестве с Qualcomm.

Supermicro X11 Intel VROC (RST) + Windows Server 201x Installer

На днях столкнулся с совсем неочевидной проблемой. Хотя что могло быть сложнее поставить Windows 2019 на новый сервер.

Материнская плата Supermicro X11DPL-i, биос обновлен до последней версии 3.3 на 20.11.2020.

Диски 2х SSDSC2KG48

Режим загрузки Legacy (UEFI глобально ничего бы не изменил).

Задача: собрать softraid на встроенном контроллере в чипсет и установить Windows Server 2019.

Почему не внешний контроллер: единственный доступный в 1U корпусе слот оказался занят сетевой картой, поэтому даже при желании его было не поставить. надо было ставить Linux и вообще ceph и все в шоколаде

1.1 Подключаем 1 диск для проверки.

1.2.1 Обращаю внимание, что на плате есть еще второй sSATA контроллер (Second SATA), который по умолчанию включен.

1.3 Ждем, где клацать Ctrl-I и не видим. Не загружается утилита конфигурации виртуального контроллера. После инициализации OpROM сетевых карт начинает грузиться с них же.

1.5 Гуглим решение: оказывается нужно как минимум 2 диска, чтобы загрузилась.

1.6 Подключаем второй диск, все начинает работать.

Вот казалось бы, вроде логично, что массив собирается только из 2 и более дисков, но почему утилита грузится с теми же требованиями?

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

2.1 Массив собрали, массив в boot menu появляется, вставляем флешку/грузим по сети/подключаем через IPMI (подчеркните сами нужное) с образом Windows Server 2019 (md5 B2626D444A641604F325B145AB0C86F1), включаем сервер

2.2 Загружается установщик, клацаем далее, встречаем пустое окно при выборе дисков.

В смысле, как так? Нету драйверов под стандартный intel raid? Такого быть не может.

2.4 ОКК, лезем на сайт Intel, ищем драйвер Intel SoftRaid/VROC, получаем пакет VROC_7.0.0.2291_F6.

2.6 Идем в биос, лазим по нему в поисках слов «raid», «intel vroc», «boot volume». В итоге понимаем, что нигде ничего нет, да и вообще, все должно работать. Лезем в Ctrl+I, у него все круто, проблем никаких, рейд собран, помечен как Bootable.

Бросаем это затею и идем гуглить.

«Supermicro X11 server 2019» «Intel VROC server 2019» «X11 softraid windows server installer»

Единственное похожее упоминание о проблеме есть тут в ветке комментариев:

Тут есть упоминание о sSATA, но к нему у нас не подключены диски, так что в итоге он был отключен вообще.

Итак, действие третье:

3.1 Вспоминаем, что у нас есть WinPE на базе Win10 (у меня это StrelecPE), пробуем загрузиться в него.

3.2 Открываем диспетчер устройств, обнаруживаем кучу неопознанных устройств, как обычно, но среди которых нету RAID-контроллера.

3.3 Значит драйвер для него установлен. да, так и есть драйвер «Intel Embedded Server RAID Technology II» установлен, успешно запустился и работает. Но в оснастке управления дисков (он же diskpart) массива так и нет.

3.3.1 ID устройства PCI\VEN_8086&DEV_2826&CC_0104

3.4 ОК, подключаем еще раз новые драйвера с сайта Intel, пытаемся скормить драйвер и вуаля, шайтан машина таки жива, диск мгновенно появляется. (Момент скрина был позже событий, поэтому система уже установлена. Изначально диск конечно же был пустой)

3.3.1 На этом моменте все умные уже предполагают, о чем будет следующее действие.

3.5 Монтируем ISO с установщиком ОС, запускаем setup.exe, диск успешно видится, система начала копировать файлы.

3.5.1 Да, можно было распаковать и через другие утилиты установки из-под WinPE, можно было через cmd распаковать сразу на диск, потом доделать загрузчик, но зачем? Если можно просто нажать далее и он сделает все сам.

3.6 setup.exe радостно сообщает, что файлы все скопировал и надо перезагрузиться.

После перезагрузки сразу получаем BSOD Inaccessible Boot Device, который как бы намекает.

Не то чтобы намекает, он напрямую говорит, что загрузчик запустил ядро, но ядро не нашло загрузочного диска. А почему?

Потому что в образе системы предустановлен тот самый драйвер, который загружается без ошибок для данного устройства, но по факту не работает.

Действие четвертое, заключительное:

4.1 Грузим опять WinPE.

4.2 Устанавливаем рабочий драйвер в WinPE.

4.3 Открываем Dism++, открываем сессию на установленную систему на дисках, импортируем туда рабочий драйвер

4.4 Перезагружаемся. Вуаля, система продолжает ставится без каких-либо проблем.

Это можно было бы сделать сразу в действии третьем (3.3.1), но так как setup.exe не предлагает не перезагружаться, в моем случае это было недоступно, да и я сам хотел проверить, заработает оно или нет без этого.

Как я предполагаю, в Intel что-то поменяли в прошивке виртуального raid-контроллера (версия Sata Option ROM 6.2.0.1034), оставив старый DeviceID. Скорее всего хотели не сломать совместимость с уже интегрированными драйверами в образах Windows Server 2012R2, 2016 и 2019. Установочные образы 2012R2, 2016 ведут себя аналогично 2019. Так и получилось, драйвер ставится, загружается, но где-то что-то идет не так и он не работает.

Я склоняюсь к этой версии, так как точно помню, что в основном Windows без проблем встают на Intel SoftRaid, без дополнительных драйверов.

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

Так как эта платформа была в единственном экземпляре, то такой порядок действии вполне нормальный, но если таких было бы несколько, то хорошим решением было бы пересобрать дистрибутив с интегрированными рабочими драйверами. Насколько такое решение является «стандартным средством» решать вам.

Источник