LINUX.ORG.RU

AMD создаёт команду для внедрения Rust в GPU-стек — от компиляторов до прошивок

 , , , ,

AMD создаёт команду для внедрения Rust в GPU-стек — от компиляторов до прошивок

0

2

5 сентября стало известно о новом направлении AMD по использованию Rust в низкоуровневом программном стеке графических процессоров. Сотрудник AMD Харш Менон (Harsh Menon) сообщил о формировании небольшой специализированной команды, задача которой — «push Rust deep into the GPU stack». В качестве направлений он перечислил компиляторы, runtime, firmware, архитектуру GPU и совместное проектирование аппаратного и программного обеспечения.

Объявление подтверждается опубликованной самой AMD вакансией Software Development Engineer — Rust, Compilers, and GPU Systems. В ней компания прямо называет Rust «core technical direction» при разработке системного ПО следующего поколения для GPU. Работы должны охватить компиляторы, runtime, низкоуровневое ПО GPU, прошивки и средства разработки. AMD отдельно подчёркивает: «Rust is not incidental to this role» — язык рассматривается не как вспомогательный инструмент для отдельных утилит.

Одной из целей объявлено превращение Rust в полноправный инженерный язык в соответствующих частях GPU-стека. Речь идёт не только о написании отдельных компонентов, но и об интеграции toolchain, создании библиотек, правил разработки, диагностики, тестирования и способов развёртывания такого кода в production. Разработчик должен заниматься как ближайшими реализациями, так и долгосрочной архитектурой применения Rust на нынешних и будущих платформах AMD.

Особое место отводится компиляторам. В описании обязанностей AMD перечислена практически вся цепочка преобразования программы: rustc → MIR → промежуточные представления и MLIR → LLVM IR → AMDGPU code generation. Планируется разработка проходов анализа и преобразования кода с учётом особенностей исполнения на GPU: отдельных пространств памяти, синхронизации, аппаратных возможностей и специализированных GPU-операций. Это указывает на работы не просто по переносу существующего host-кода на Rust, но и по развитию инфраструктуры, необходимой для использования Rust значительно ближе к исполняемому на GPU коду.

Другим направлением станут интерфейсы между различными уровнями системы. AMD собирается разрабатывать типизированные и пригодные для аудита границы между компилятором, host runtime, кодом GPU, firmware и аппаратурой. Отдельно упоминаются ABI, размещение аргументов, calling conventions, работа linker и loader, ELF и метаданные AMD GPU code objects. Таким образом, ставка делается не только на защиту памяти, обычно ассоциируемую с Rust, но и на уменьшение числа ошибок на границах между компонентами сложного GPU-стека.

В самой вакансии AMD подчёркивает, что memory safety не решает проблему корректности целиком. Для GPU-систем имеют значение конкурентный доступ, порядок выполнения операций, совместимость ABI, поведение устройства и преобразования, выполняемые компилятором. В перечне требуемых областей знаний поэтому фигурируют также анализ программ и formal methods — предполагается формализовать часть предположений, существующих между программным обеспечением и аппаратурой, и проверять их при разработке.

Rust планируют применять и ещё ниже — в средах без полноценной стандартной библиотеки. AMD прямо упоминает разработку или усовершенствование bare-metal и no_std компонентов на Rust, где требуется предсказуемое взаимодействие с аппаратурой, ограниченное состояние и контролируемое поведение при ошибках. В сочетании с отдельно названным firmware это означает, что область эксперимента не ограничивается пользовательскими библиотеками и компиляторами.

Для Linux направление представляет дополнительный интерес из-за структуры программного стека AMD. ROCm распространяется как открытый программный стек для вычислений на GPU и включает средства разработки, API, runtime, компиляторы и взаимодействует с драйвером AMDGPU. В документации ROCm сама AMD описывает современный стек своих ускорителей как взаимозависимый набор из GPU firmware, драйвера AMDGPU и пользовательских компонентов ROCm.

При этом из объявления не следует, что AMD собирается переписывать существующий драйвер Linux amdgpu на Rust. В первоисточниках говорится шире о «low-level GPU software», firmware, runtime и компиляторах, но конкретного плана замены написанных на C частей amdgpu не опубликовано. Поэтому формулировки вроде «AMD переводит Linux-драйвер на Rust» на данном этапе были бы преждевременными.

Не объявлено и то, что весь создаваемый на Rust код обязательно станет открытым. Значительная часть Linux- и ROCm-стека AMD развивается как открытое ПО, однако в новой вакансии речь идёт прежде всего о технической архитектуре и production-разработке, а условия распространения будущих компонентов там не определены.

Таким образом, пока речь идёт не о завершённом продукте или переносе существующего проекта, а о формировании внутри AMD отдельной компетенции по системному Rust для GPU. Судя по перечню задач, компания рассматривает язык сразу на нескольких уровнях — от rustc, MLIR и LLVM до runtime, ABI, firmware и взаимодействия непосредственно с аппаратурой. Насколько далеко Rust в итоге проникнет в открытый Linux/ROCm-стек AMD, станет понятно после появления первых результатов работы новой команды.

>>> Источник

★★★★★

Проверено: cetjs2 ()
Ответ на: комментарий от Gonzo

та не... сама иишка будет крутиться в облаках... очевидно-же :о)

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

Ну, не без армии полезных идиотов

просто : не без армии!

sunjob ★★★★★
()

Куда смотрит кровавая администрация? Почему на глагне новость о намерениях?

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

Базовая цена $1999[Max]-$3999[Ultra]
да, с такой ценой они уделают ... скорее сами себя.
время «широкого» применения макак - прошло. будем ждать когда «что-то» придумают. а пока разумный покупатель будет решать «рублем». (имхо, спорить не буду :о)))

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

На том же Паскале, например, они пишут гораздо хуже

ваще отвратительно... постоянно тыкаешь носом, а он тебе
- ой, и в самом деле, вы правы! :о)

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

Те же «личности» что внедряют в мейнстрим systemd, gnome etc...

а лёня-то беленький, симпатишный... думаешь, прикидывается? :о)

sunjob ★★★★★
()
Ответ на: комментарий от lefsha
CXXFLAGS+=" -std=c++11" ... итд
sunjob ★★★★★
()
Последнее исправление: sunjob (всего исправлений: 1)
Ответ на: комментарий от bbc69

А какой резон рептилоидам от внедрения системД.
Он ведь всего лишь призван стартовать демоны

так о демонах-же речь! :о)

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

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

sunjob ★★★★★
()
Последнее исправление: sunjob (всего исправлений: 2)

Серьёзно, затачивать железо для выполнения кода на расте?

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

Нет, я ему вполне верю. Индусов в ИТ вообще много. Кстати, причина та же самая, почему в IT много русскоязычных.

VIT ★★★
()

Этот язык НАСТОЛЬКО хорош, что его нужно насильно пропихивать куда бы то ни было, лишь бы им хоть кто-то пользовался реально, а не перепишем переписанное?

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

А вот скажите - их кто то заставляет - тайное мировое правительство

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

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

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

unixnik ★★★★★
()

Как там хейтеры? Уже просят немножечко вынуть и не внедрять так быстро? :-D

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

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

На тот случай, если вы последние пару-тройку лет уезжали с Земли, у нас тут код подешевел, фактически бесплатный стал, программисты работу ищут. В талксы заглянете, если время будет…

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

Есть порог применения? Не вынуждает ли это требование полностью переписать код? Или дается какой то период времени на переход, но не прямо немедленно?

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

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

Lucky ★★
()

В новости есть все как мы любим, кроме мотивационной части. Есть ли она у амудей?

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

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

Если у кого-то вообще возникает такой вопрос, то что-то явно не так в консерватории.

Поломка обратной совместимости - это рак софтостроения. Сборка приколоченная гвоздями к определённой версии библиотеки - сифилис. А приколачивание гвоздями непременно к наипоследнейшей версии библиотеки это вообще monkeypox.

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

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

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

Вы ровным счетом НИЧЕГО не поняли. 99.9% программ, которыми вы пользуетесь написаны ДРУГИМИ людьми и не вами.

Ваше желание просто собрать эту программу, чтобы она работала. Когда автор ее писал он вообще не думал про версии. В то время не было даже -std=c++11 не говоря о других. Это не считая факта, что некоторые особенно альтернативно развитые программисты пишут под -std=gnu++11

Спустя годы вышла новая версия gcc, которая говорит - ой-ой - ТАК? - делать нельзя. Это опасно. И у вас все накрывается. Какие варианты? Сидеть патчить ЧУЖОЙ код? Или ставить «правильную» версию стандарта?

Ну ок. «вчера» была только одна правильная версия - -std=c++11. Сейчас их 5-6. Завтра их будет 26.

До вас доходит, что это поиск проблем на свою задницу?

Казалось бы - напиши в коде версию языка, которую используешь и все! проблема решена раз и на всегда! Сделай расширение - main.c++26 - и все поймут какая там версия.

НО НЕТ! мы не ищем решение проблем. мы ищем геморр!

И ровно по этому уже Rust - на порядок лучше. Мне не нравится синтаксис, но для большого проекта без поиска проблем через 5 лет лучше пока ничего нет. Альтернативно - C# и F# - у ребят из MS - очень хорошо с головой в отличие от комитета С++.

Но сейчас все крутится на C++ и это ужасно.

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

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

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

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

Как бывший работник amd могу сказать что там давно «индусский менеджмент».

Жуть… Это как приговор компании. Хотя топом у них вроде китаянка… Или она не может с ними справится?

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

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

https://www.rustfaq.org/en/understanding-rust-editions-2015-2018-2021-and-2024/

An edition is a flag that switches the parser and some semantic checks. When you compile a crate, rustc reads the edition from the manifest. It loads the corresponding grammar table. If the edition is 2021, the parser recognizes let chains in conditionals. If the edition is 2018, the parser treats that same syntax as an error.

This mechanism prevents the «Python 2 vs 3» problem. Python 3 broke the syntax of Python 2. Millions of packages had to be rewritten. Rust editions avoid that breakage. Code written for 2015 compiles on 2018, 2021, and future editions. The language moves forward, but the past remains accessible.

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

В пределах 3-й версии (а до того 2-й) языковые конструкции языка Python снизу вверх очень хорошо совместимы. За этим тщательно следят. Проблемы в создателях пакетов, многие из которых часто ломают совместимость, отсюда ад зависимостей и кучи venv.

Ну конечно… только сказки не надо рассказывать! Кому угодно - только не мне.

В системе специально питон стоит в слотах и условно говоря если вы обновите его на сильно более новую версию, то все скрипты упадут. И КАЖДЫЙ раз нужно обновлять скрипты прыгая с версии на версию.

Возьмите тот же freecad и убедитесь сами. По этому МИЛЛИОН пакетов требуют определенную версию питона. И если у вас сильно разные пакеты, то у вас заведомо стоит 2 или 3 питона как минимум.

Головой подумайте - если язык один - как создатели пакетов могут ломать совместимость ЕСЛИ все одинаково! Тогда абсолютно без разницы какую версию брать!

Еще один классический пример!

Поставьте себе dev-util/nvidia-cuda-toolkit

Вы увидите что он поддерживает gcc-15, но не поддерживает gcc-16…

Как же так? Ведь это так легко поставить -std=…

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

А что случилось???

А может таки проблема не с NVIDIA, а с дебилами которые писали gcc и которые придумывают стандарты для C++?

И таких примеров масса. Но разумеется на все можно закрыть глаза и сказать, что ничего этого нет.

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

В чужом проекте, если автор - не идиот, он укажет -std.

Наивный юноша… И откуда такие берутся.

Стандарт языка компиляции - это выбор программиста, автора пакета. Неотъемлемая часть кода, как .cpp и .c файлы.

А если головой попытаться подумать? Ну хотя бы ИНОГДА.

Т.е. стандарт языка это неотъемлемая часть кода… например main.cpp хорошо… А указывать ее надо в…. Makefile…

Никаких проблем не возникает? Нет?

Вот я ровно об этом и пишу. Что ЭТО придумали полные ИДИОТЫ. У них очень и очень плохо с мозгами.

Заболел один, а лекарство дают другому… Ну а как еще… это же очевидно.

И если автор говорит - так нафига мне стандарт указывать, если он идет по умолчанию. Мне сам компилятор говорит - работаем с этим стандартом. А что там будет через 5 лет - мне глубоко нас***.

Вы серьезно никогда не встречали такие пакеты?

Я тут уже написал одному оратору. Изучите вопрос с dev-util/nvidia-cuda-toolkit

И расскажите мне - в чем именно идиоты из NVIDIA. Может ликбез среди них провести как код на С++ писать?

Или все таки проблема в этом ущербном языке и авторах ущербных компиляторов?

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

Вы ровным счетом НИЧЕГО не поняли.

Да нет, я всё понял, а вот кто-то не понял мой ответ.

Ваше желание просто собрать эту программу, чтобы она работала. Когда автор ее писал он вообще не думал про версии. В то время не было даже -std=c++11 не говоря о других.

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

Это не считая факта, что некоторые особенно альтернативно развитые программисты пишут под -std=gnu++11

С gnu++11 всё в порядке, что за наезд?

Ну ок. «вчера» была только одна правильная версия - -std=c++11

А как же c++98? Впрочем, я пытался на нём писать как-то и тоже пришёл в выводу что лучше поставить c++11, но не стоит это в абсолют возводить.

И ровно по этому уже Rust - на порядок лучше.

А что, в rust в расширении файла указана нужная версия компилятора? Иначе непонятно как это заявление связано с предыдущими наездами на С++.

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

Глупости.

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

смешно! :о)

sunjob ★★★★★
()
Последнее исправление: sunjob (всего исправлений: 2)

«push Rust deep into the GPU stack»

Лучше б он как обычно deep присел на бутылку посреди очередного корпоратива…

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

То есть тайное правительство. А им какая от этого выгода? Мне первопричины понять.

Контроль. Через эти истории можно: запретить собирать приложения, внедрить шпионские истории в любой момент, снизить производительность железа и т.п.

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

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

А что случилось???

А может таки проблема не с NVIDIA, а с дебилами которые писали gcc и которые придумывают стандарты для C++?

Даже мне стало интересно. Нейронка говорит в этом пакете нвидии их собственный компиллятор gpu-исполняемого кода берет хидеры от gcc. И в 15-16 версиях хидеры идут с новыми gcc-специфичными ключевыми словами. Кто-то кому-то показывает фак.

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

Старые пердуны этого не то что написать, осознать бы не смогли что тут вообще происходит. Значит в принимающие решения пролезли молодые и шибко деятельные. У кого то в жопе засвербело и он решил «сделать мир лучше».

Это единственное адекватное объяснение. Впрочем, это объясняет вообще все события в мире в последнее время.

Так можно объяснить все что угодно, поэтому можешь не надеется на адекватность своих оценок… По опыту, скажу: если вдруг что-то начинают Усиленно внедрять (пусть даже и со стороны причины выглядят глупо), значит План точно есть, и на этом кто-то что-то поимеет, а у кого-то что-то отберут… Классика.

ЗЫ тебе пенсионную реформу провели под лозунгами «теперь вы сможете работать еще 5 лет спокойно»…

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

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

Как по одной фразе понять, что человек не руководил ни чем, кроме , возможно своей самозанятости.

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

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

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

Как по одной фразе понять, что человек не писал на Си, но много про него читал :))

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

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

А в чем проблема то? С открытым драйвером для linux эти бюджеты с армиями не справились. Черные экраны под виндой стали притчей во языцех. Да, программисты nvidia рукожопы так же как и остальные

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

Самый главный, например, - это сраная libicu, в которой конченные долбодятлы ломают бинарную и сырцовую совместимость с каждой, сцуко, минорной версией

А теперь поподробнее, пожалуйста.

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

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

а с другой стороны не дает сделать элементарные вещи с типа заботой о тебе.

Это как в том анекдоте - убивайте кого хотите, только не курите…

Глупости пишешь, вообще не осознаешь что и зачем…

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

Ну даже не знаю:

  • Адекватные разработчики, которые не бегают по гитхабу, создавая рандомные issues с «переписать всё на раст!»
  • Нет малвари в библиотеках в репозитории
  • Не создают иллюзию безопасности, указывая на только один класс ошибок, напрочь игнорируя остальные
  • Есть чёткие стандарты языка
  • Нет проблемы работать с библиотекой, созданной под другим стандартом (в расте нельзя использовать пакет более старой редакции, если там, например, макросы старого формата)
  • Нет миллиона автоматически линкуемых лефтпадов, за которую никто не несет ответственности. Вы можете использовать 1 проверенный крейт, но кто-то в цепочке будет использовать ещё 10-100-1000 заброшенных (и, возможно, угнанных).
  • Нет монополии одного компилятора (вы можете сделать только «совместимый» компилятор, не «компилятор языка Rust», потому что Rust - патентованное название).
PPP328 ★★★★★
()

А что у них там с самими GPU-то? Я чот поискал, условные MI325X/MI350 даже в аренду негде взять потестить))

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

Чего ты переживаешь - новые придумают. Долго ли умеючи?

sparkie ★★★★★
()
Ответ на: комментарий от shkolnick-kun

О подготовке кадров сейчас думать некогда, - мировой экономический кризис на носу. Так что в дело вступает Основной принцип капитализма: умри ты сегодня, а я - завтра.

Именно так и будет, узкие специалисты, а потом и просто специалисты просто исчезнут. Причём не только в софте.

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

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

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

Одна надежда на большой ИИ

sena ★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.