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

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

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

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

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

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

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

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

Нет, это чтобы ржать над кудахерами.

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

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

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

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

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

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

потому что унштабле ядерное апи. а унштабле оно потому, что линусу достаточно ограничений из-за поддержки юзерспейсного апи/аби

Нестабильное апи - признак фиговой архитектуры

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

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

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

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

справляются

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

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

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

Собирай без них, в чём проблема?

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

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

Где почитать про эффективность FSGSBASE на процессорах r5 3600

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

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

Нестабильное апи - признак фиговой архитектуры

Приехали… И это на ЛОРе…

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

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

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

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

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

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

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

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

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

А на лоре можно только уверовать и не возбухать?

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

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

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

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

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

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

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

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

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

Я не про модули, а про то, что все одной гиганской репой идет.

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

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

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

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

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

ещё немного и линукс будет готов.. к покупке микрософтом ;)

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

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

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

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

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

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

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

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

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

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

Что-то мне подсказывает, что будет просто ещё один новый механизм.

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

Для вычислений

вот тут и ответ

Они хотя бы баг с NVMe поправили, из-за которого некоторые дистрибутивы до сих пор держат на ядре 5.6? А то знай только новые функции вводить своими криворукими руками, а баги исправлять они типа не обязаны.

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

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

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

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

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

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

В Netfilter добавлен REJECT на стадии PREROUTING

:) Это ж сколько десятилетий понадобилось?

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

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

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

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

все одной гиганской репой идет

это огромный плюс - не надо искать драйверы

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

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

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

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

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

ага, зато хочешь обновить драйвер - качай новое ядро

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 постоянно опрашивает видеокарту на наличие этой фичи, т.к. в иксах этих сообщений не наблюдаю

венда распространяется с кучей дров и занимает десять+ гигов

зато хочешь обновить драйвер - качай новое ядро

часто ты такое делаешь ?