LINUX.ORG.RU

Вышло ядро версии Linux 5.9 добавлена поддержка FSGSBASE и Radeon RX 6000 «RDNA 2»

 ,


0

1

Линус Торвальдс объявил о стабилизации версии 5.9.

В числе прочих изменений он внес в ядро версии 5.9 поддержку FSGSBASE, которая должна улучшить производительность переключения контекста на процессорах AMD и Intel. FSGSBASE позволяет читать и изменять содержимое регистров FS/GS из пространства пользователя, что должно улучшить общую производительность, пострадавшую после закрытия уязвимостей Spectre/Metldown. Сама поддержка была добавлена инженерами Microsoft несколько лет назад.

Так же:

  • добавлена поддержка Radeon RX 6000 «RDNA 2»
  • добавлена поддержка команд зонирования накопителей NVMe (NVMe zoned namespaces (ZNS))
  • начальная поддержка IBM Power10
  • различные улучшения подсистемы хранилищ, ужесточена защита от использования GPL-прослоек для связывания проприетарных драйверов с компонентами ядра
  • модель потребления энергии (фреймворк Energy Model) теперь описывает не только поведение энергопотребления CPU, но и периферийных устройств
  • В Netfilter добавлен REJECT на стадии PREROUTING
  • для AMD Zen и более новых моделей CPU добавлена поддержка технологии P2PDMA, позволяющей использовать DMA для прямой передачи данных между памятью двух устройств, подключенных к шине PCI.

>>> Подробности

★★★★★

Проверено: maxcom ()

ужесточена защита от использования GPL-прослоек для связывания проприетарных драйверов с компонентами ядра

Это не про блоб от нвидии, случайно? Ему что-нибудь грозит?

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

Не только, но в том числе. В данном релизе нет, но в комментариях на Опеннете кто-то считает, что просто не успели в этом ядре, и сделают в следующем.

Фрагмент новости на Опеннете

Обратная блокировка (экспорт только EXPORT_SYMBOL_GPL в модулях, импортировавших EXPORT_SYMBOL_GPL), которая могла нарушить работу проприетарных драйверов, не реализована (наследуется только флаг проприетарного модуля, но не GPL-привязки).

ZenitharChampion ★★★★★ ()

P2PDMA, позволяющей использовать DMA для прямой передачи данных между памятью двух устройств, подключенных к шине PCI

Но ведь PCI-E начиная с 1.0 такое умел просто по самой сути работы шины, речь про механизм чтобы устройства получали информацию друг о друге через подобный механизм? Правда, если видеокарта и другое устройство торчат через разные root-порты тогда наверное нужны специальные пляски, которые это P2PDMA видимо и обеспечивает

I-Love-Microsoft ★★★★★ ()

добавлена поддержка Radeon RX 6000 «RDNA 2»

просто прекрасно, но зачем драйвера в само ядро тащить? Не лучше ли драйвера отдельно, ядро отдельно? Как в том же windows, например. А то что-то ядро совсем распухло уже

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

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

gag ★★★★★ ()
Ответ на: комментарий от cvs-255

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

anonymous ()
Ответ на: комментарий от anonymous

Как то же в винде справляются и не тащат все драйвера в ядро?

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

cvs-255 ★★★★★ ()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от cvs-255

справляются

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

не тащат все драйвера в ядро

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

anonymous ()
Ответ на: комментарий от cvs-255

Как то же в винде справляются и не тащат все драйвера в ядро?

У винды ядро гибридное и большинство драйверов в юзерспейсе. Да и там ломают, но есть тонны сахара в виде DDK/WDK. Собственно, см. релизы DDK/WDK. И да, дрова под Винды делать тоже тот ещё адок. У меня опыт, конечно, весьма скромный, но я бы не сказал, что сильно проще, чем Линуксовые (даже с учётом ломок внутриядерного API/ABI).

SkyMaverick ★★ ()
Ответ на: комментарий от ZenitharChampion

сделают в следующем

MS добавляет плюшки в WSL, Линус, напротив, всеми возможными способами ослажняет жизнь пользователям. Конец, кмк, немного предсказуем.

anonymous ()
Ответ на: комментарий от cvs-255

просто прекрасно, но зачем драйвера в само ядро тащить?

Когда все в одной репе - поддерживать, обновлять, рефакторить это сильно проще. Ну и все работает «из коробки».

Не лучше ли драйвера отдельно, ядро отдельно?

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

Как в том же windows, например.

Хороший пример, почему так делать не нужно. У меня куча переферии (принтеры там, сканеры) которая сейчас работает только под линуксом (а лет 10 назад работала только под шиндой). Да, есть и то, что сейчас не работает вообще нигде (и работало 10 лет назад под виндой), но это все равно показательно.

А то что-то ядро совсем распухло уже

Сиди на генте, собирай только нужные модули.

derlafff ★★★★★ ()
Ответ на: комментарий от cvs-255

Раньше шиндовз понтовалась драйверами в ядре и что их не надо ставить. Так нафига их оттуда убирать? Ядро весом 110 мегабайт тебе не скачать? На диске исходники 1,3 гигабайта занимают, но в собранном виде ядро 8,3 мегабайт. С системмап 11,3 мегабайт. Покажи ядро шиндожз и сколько оно весит с драйверами в том числе на ввидеокарту.

anonymous ()
Ответ на: комментарий от anonymous

Void, монолитное ядро с kernel.org. Послать тебя куда-нибудь следовало бы. Ядро на любой системе собирается за несколько минут.

Как этот поток сознания относится к тому, что я сказал?

derlafff ★★★★★ ()
Ответ на: комментарий от cvs-255

Вот еще хохма: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-Stats

10% от общего объема, 2 миллиона строк кода (из которых правда 1.7 это автосгенерированные заголовки). Ну и поддержка новых девайсов путем копипасты кода для старых

Midael ★★★★★ ()
Ответ на: комментарий от Midael

из которых правда 1.7 это автосгенерированные заголовки

Исходный код такой исходный….

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от hobbit

https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/...

Там история была в том, что кто-то из фейсбука предложил код для DMA zerocopy между сетевой картой и гпу для кластеров. Ну а так как proof of concept был сделан для нвидии, то fuck nvidia.

Midael ★★★★★ ()
Ответ на: комментарий от derlafff

Сиди на генте, собирай только нужные модули.

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

anonymous ()

модель потребления энергии (фреймворк Energy Model) теперь описывает не только поведение энергопотребления CPU, но и периферийных устройств

Вызывает антерес сберегический процесс. Как теперь всё будет греться, с уэсбэшкой али без?

Выбешивает то, что непонятно кто занимается режимами энергосбережения и как определяется когда уводить устройство в сон? Что-то насыпано в модулях ядра, что-то слушает acpi, powertop постоянно недоволен тем, что устройства не энергосберегаются, но попробуй сделать так, чтобы ему нравилось, получишь щелчки в звуковухе во время засыпания/просыпания оной, засыпание усб устройства во время копирования на него файлов и пр. И ещё alp воображает, что лн лучше знает кому когда спать и как уменьшать частоту проца (иксруны в джеке) и может ещё кто управляет? Я уже запутался следить.

Они сделали серебрянную пулю?

ChekPuk ★★★ ()
Ответ на: комментарий от Shaman007

Последнее - это чтобы текстуры в играх прямо в видеокарту из PCIe4 nvme грузить, да?

Сомневаюсь что это ВООБЩЕ возможно в текущем виде. Текстуры находятся в файле-контейнере, который может быть упакован уже в контейнер с другими ресурсами игры. Контейнер сам может быть сжат или зашифрован. Всё это дело лежит в файловой системе и может быть фрагментированным.

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

И всё-равно - данные для такой передачи придётся предварительно подготовить с помощью ОС - распаковать их из всех контейнеров и положить в специальную зону на SSD (файл-подкачки?) из которой текстуры можно будет быстро достать простой командой.

В общем, на текущий момент - это фантастика. Если где такое и будет реализовано в ближайшее время - то только на консолях.

DawnCaster ()
Ответ на: комментарий от DawnCaster

Это фича новых консолей (емнип, PS5), которая позволяет им быстро подгружать новые уровни. Понятно, что данные специальным образом подготовлены для такого рода фокусов. Конечно, нужен протокол, вон там еще какие-то команды зонирования nvme упоминаются, не знаю еще что это такое. Для вычислений тоже выглядит полезно, когда данные уже подготовлены в нужном виде и хочется быстро откормить их вычислителю.

Shaman007 ★★★★★ ()
Ответ на: комментарий от Shaman007

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

Да нету там никаких новых фич. Маркетолухи просто уже из кожи вон лезут с этим своим сраным SSD, т.к больше в PS5 никаких отличительных вещей нет от слова совсем.

Не будет там никакого зонирования, прямой передачи и вот этого всего. Там обычный говно-SSD с TLC памятью и физической скоростью передачи данных не дотягивающей даже до последних самсунгов. И объем диска всего 800 гигов. Распакованные текстуры подготовленные для видяхи весят целую тонну (даже если их слегка пожать DXC\ST3C и.т.д), на такой диск их некуда класть.

Ну и самое главное - игры в 90% случаев нынче кросс-платформенные. И делаются на стандартных движках. Другие подходы к разработке ААА игры становятся нынче просто космически дороги. Так что не надейтесь ни на какую сверх быструю загрузку и вот это вот всё что там наврали маркетологи SONY на презентации. Геймдев - это одно сплошное вранье. Поверьте мне как человеку потратившему на это дело 5 лет жизни.

DawnCaster ()
Последнее исправление: DawnCaster (всего исправлений: 1)
Ответ на: комментарий от DawnCaster

Распакованные текстуры

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

anonymous ()
Ответ на: комментарий от anonymous

Ещё раз прочитай что я написал. Текстуры даже в таком виде упакованном в DXTC\S3TC и.т.д - занимают место. Современные игры не просто так весят по 100 гигов. И вот каждую текстурку из дистрибутива игры надо будет подготовить таким образом что-бы она могла напрямую попасть с SSD в видео-память (то есть - положить копию в другую область на SSD). В общем, для современных TLC SSD с их скоростями и ресурсами записи - это задача неподъемная.

DawnCaster ()
Последнее исправление: DawnCaster (всего исправлений: 2)
Ответ на: комментарий от cvs-255

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

теперь у нас новости типа «в ядро добавлен драйвер радеона, но это всё равно не заработает без месы» в которой есть ещё один драйвер, который тоже всё равно не заработает.

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

anonymous ()
Ответ на: комментарий от DawnCaster

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

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

а расскажи что-нибудь про враньё.

anonymous ()
Ответ на: комментарий от anonymous

лучше дрова в юзерспейсе

Я не столько про юзерспейс/кернелспейс, сколько про модель распространения. Одним большим дистрибутивом или ядро отдельно распространяется, драйвера отдельно

cvs-255 ★★★★★ ()

P2PDMA

из-за этой хрени мне приходится каждый раз патчить ядро чтобы отключить бесконечный флуд в dmesg вида: radeon 0000:02:00.0: cannot be used for peer-to-peer DMA as the client and provider (0000:03:00.0) do not share an upstream bridge or whitelisted host bridge.

Подозреваю что Wayland постоянно опрашивает видеокарту на наличие этой фичи, т.к. в иксах этих сообщений не наблюдаю

d1on1s ()