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 ()
Ответ на: комментарий от saahriktu

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

Да, верно. Но так как армия программистов на Си\Си++ генерирует тонны висящих указателей и NULL dereference, то и код, на котором обучается ИИшница - такой же, низкого качества. Обучают ее на кодовой базе X11, а там через месяц нашли 10 CVE. А ИИшница уже всосала паттерны программирования. Поэтому говорят, что ИИ на Си\Си++ - ъуже. Не в том смысле, что ИИ виновата. Программисты на Си виноваты.

При использовании Раста агент использует компилятор как часть контура своего. Там тяжело накосячить - компилятор не пропустит. И интерационной разработкой рано или поздно получится рабочий код, который удовлетворяет компилятор Раста.

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

Чтобы её можно было использовать для кодогенерации

Это и имел в виду, собсно. Посадить. За пульт управления. Это только начало.

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

Это одна из причин. Вторая, конечно же, лицензия. Всё-таки не в условной Индонезии находимся, лицензии в Калифорнии худо-бедно соблюдаются. Поэтому если уже переписывать, то на правильной лицензии.

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

Рептилоиды с планеты Нибиру управляют американским правительством, в том числе и ИТ, давно уже пора это понять. Они через боссов корпораций управляют процессами. Те же «личности» что внедряют в мейнстрим systemd, gnome etc...

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

При использовании Раста агент использует компилятор как часть контура своего.

Здесь очень важно не только то, что сам язык допускает меньше UB, но и сообщения компилятора. В этом смысле Gnu Compiler Collection является таким аутсайдером, что никому, ну кроме известного на этом сайте персонажа, даже в голову не придёт это серьёзно использовать. LLVM проделал очень серьёзную работу над ошибками в плане диагностики, но косяки Си или Си++ с неоднозначностью исправить компилятором не получится.

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

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

То что инопланетная разумная форма жизни управляет правительством США не адекватное объяснение?

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

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

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

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

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

Это не так работает. Как же много заблуждений и про нейросети, и про Rust...

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

Ну и что касается Rust'а, то компилятор за ошибки по пальцам, конечно, бьёт, НО в том-то и дело, что если оператор ИИ ничего в Rust'е не понимает, то он вполне может войти в бесконечный цикл исправлений и никакого результата не будет. Избежать его можно только в том случае, если разработкой занимается грамотный программист, который может сам разрулить возникающие ошибки.

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

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

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

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

Очень просто делается - опцией компилятора задаете версию и смотрите - скомпилировалось или нет :). Что это за код такой , интересно? Си++ активно меняется, да. Но Си…

??? Вы вообще поняли что сказали???

Есть ЧУЖОЙ проект. В котором уже все есть. Все настроено. Вы просто хотите это собрать. НО… У вас обновился компилятор, который ОПППС по умолчанию решил, что будет использовать ДРУГОЙ стандарт языка. И все ваша сборка падает от кучи ошибок.

Вот такое сделали гении стандартов. И я уверен более чем на 50%, что можно написать код, который будет собираться разными версиями компилятора, но этот код будет делать разные вещи в каждой версии!

В Rust в одном из немногих языков эта проблема таки решена.

Уже ради этого не стоит использовать С и тем более С++. Его придумали идиоты.

Им понравилась игра Python2 vs Python3, которая продолжается по сей день, когда каждая новая версия не совместима с предыдущей.

Я не понимаю ЧТО у людей писавших питон было в голове, скорее всего НИЧЕГО.

В этом смысле Rust - опять гениальный язык. Его cargo - это просто чудо какое-то по сравнению с cmake.

cmake тоже писали идиоты.

И да, Rust сложноват и перегружен всякими вспомогательными макросами. В этом смысле ZIG лучше.

Но с учетом Wibe coding это теряет значение. Но в остальном Rust кладет все остальное на лопатки.

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

а вы, уважаемый, говорили, что уже было, 2 страницы обсуждения заговора рептилоидов, за это мы и любим ЛОР:)

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

И я уверен более чем на 50%, что можно написать код, который будет собираться разными версиями компилятора, но этот код будет делать разные вещи в каждой версии!

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

Однако, что касается стандартов то вот пример разного поведения в C89 и C99, при том что оба успешно компилируют прогу:

Завершился IOCCC'24 (комментарий)

Уже ради этого не стоит использовать С и тем более С++. Его придумали идиоты.

А вот тут ты совершенно не прав. Си, конечно, следует использовать, почти везде.

cmake тоже писали идиоты.

cmake да, плохой и ненужный. Можно пользоваться обычным make или вообще build.sh скриптом.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 3)
Ответ на: комментарий от lefsha

А что, не скомпилится? С -std=c89 скомпилится, zlib почти на K&R написан например.

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

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

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

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

Или можно так понимать, что вместо развития ROCm распыляют силы на эксперименты с Rust. Трудность компилирования ROCm от этого не уменьшится, а увеличится. И это при том, что ROCm до сих пор требует возни, чтобы установить их в произвольном дистрибутиве Linux.

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

Cmake действительно здодолбучий. То что make хуже это наследие далекого прошлого, которое cmake использует. Вместо cmake есть ведь и autoreconf(это не autoconf). Я им пользовался и могу сказать что он удобнее в плане сборки. У cmake есть поганая фишка что все что все зависимости должны быть собраны с cmake и не дай бог там появятся пакеты с одинаковыми именами.

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

Для сборки удобнее всего шелл-скрипт.

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

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

Как бывший работник amd могу сказать что там давно «индусский менеджмент». Разработку драйверов они в Бангалор отправили еще в 2013м. Драйвер для линукса fglrx вообще китайское подразделение делало партизанским способом, потому что позиция менеджмента была: никакого линукса. Там буквально 4 человека работало над задачей и то когда время было

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

В Rust в одном из немногих языков эта проблема таки решена.

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

Им понравилась игра Python2 vs Python3, которая продолжается по сей день, когда каждая новая версия не совместима с предыдущей.

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

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

Это не так работает. Как же много заблуждений и про нейросети, и про Rust…Нейросети ничего не копипастят из примеров. Они учатся по этим примером угадывать ответ.

Я написал, что сети обучаются ошибочным паттернам программирования.

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

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

Это взаимовыгодное сотрудничество Антропиков и больших софтверных компаний. Никому не нужен сеньор, который до сеньера растет 5-10 лет, и которого потом страшно выгнать, потому, что замену ему сложно найти.

Оптимизация!

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

Есть ЧУЖОЙ проект. В котором уже все есть. Все настроено. Вы просто хотите это собрать.

НО… У вас обновился компилятор, который ОПППС по умолчанию решил, что будет использовать ДРУГОЙ стандарт языка.

И все ваша сборка падает от кучи ошибок.

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

Вы когда релизите свой проект, у вас там лежит скрипт сборки. Makefile, там, или еще что. Вот там в файле вы указывает -std=c11 или , что вы там любите. Стандарт языка компиляции - это выбор программиста, автора пакета. Неотъемлемая часть кода, как .cpp и .c файлы. Если автор не указал - возможно он писал на ANSI С. Тогда просто напишите -pedantic.

vvb333007
()
Ответ на: комментарий от lefsha
/* gcc -std=c90 test.c */
#include <stdio.h>

main()
{
    printf("hello, world\n");
}
D:\EFRR>gcc -std=c90 test.c

D:\EFRR>gcc --version
gcc (GCC) 14.4.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
vvb333007
()
Ответ на: комментарий от vvb333007

это позволит не искать узких спецов с опытом

Это не так работает. Уровень современных Имитаторов Интеллекта - тупорылый джун-активист. LLM может взять на себя только рутину, самое сложное придется делать теми самыми узкими спецами, которых все равно придется искать.

А вот десяткам тысяч джунов придётся переквалифицироваться в собачьи парикмахеры.

мимо-вайбкодер-со-специфичными-сферами-интересов

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

если оператор ИИ ничего в Rust’е не понимает,

Зато, если он понимает в TDD, BDD, мутационном и гиркин-тестировании, как Дядя Боб, то ему становится пофиг, на чём генерируются исходники, и ни в какой цикл от не попадёт.

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

А вот десяткам тысяч джунов

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

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

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

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

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

Cmake действительно здодолбучий. То что make хуже это наследие далекого прошлого, которое cmake использует. Вместо cmake есть ведь и autoreconf(это не autoconf). Я им пользовался и могу сказать что он удобнее в плане сборки.

Смешались в кучу люди, кони.

Исторически cmake затачивался под x86_64-pc-windows-msvc.

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

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

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

Исторически-не исторический а cmake привозит с собой целую систему дополнительных файлов. Но при этом он вообще не предполагает конфликтов имен пакетов

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

Вот такое сделали гении стандартов. И я уверен более чем на 50%, что можно написать код, который будет собираться разными версиями компилятора, но этот код будет делать разные вещи в каждой версии!

На хабре читал статью, что С/С++ такой, потому что они пытались в обратную совместимость любой ценой. А тут я читаю, что оказывается, у них что-то не сходится.

Им понравилась игра Python2 vs Python3, которая продолжается по сей день, когда каждая новая версия не совместима с предыдущей.

Про питон 2 уже все забыли. Вы из какой криокамеры вылезли?

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

Исторически-не исторический а cmake привозит с собой целую систему дополнительных файлов. Но при этом он вообще не предполагает конфликтов имен пакетов

У тебя autoreconf должен брать либы и флаги через pkg-config. CMake тоже ищет пакеты через pkg-config. Установленные дев-библиотеки должны класть информацию в pkg-config. У тебя странная проблема. Да собственно и легко разруливается через переменные окружения.

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

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

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

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

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

gcc -g -O2 -c a.c -o a.o
gcc -g -O2 -o a.out a.o -lm -lpthread 

например. Посчитайте размер созданного мусора так называемых «временных файлов».

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

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

Я не работаю cmake-адвокатом. Меня забавляет, когда людям достаточно однострочника, или достаточно Makefile.

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

никто из них не является разрабом на C или Rust, но мнение имеет.

Ну, я когда-то программировал на Strict ANSI C89. Глядя на современные C++/Rust, мне за них браться вообще не хочется. С другой стороны, пластиковый мир победил, браться уже и не нужно, вон пусть ИИшница всё это месиво разгребает.

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

Я не работаю cmake-адвокатом.

Ну тогда извиняйте, показалось.

Меня забавляет, когда людям достаточно однострочника, или достаточно Makefile.

Гигантизм? Проект меньше миллиона строк не достоин права на существование?

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

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

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

Мне виднее потому что я там работал. Я знаю что например команда закрыть офисы в России и Украине прошла в октябре 2013го. Если чо на 2013й год половина разрабов в Монреале из РФ достались от ATI. Еще половина китайцы. Есть немного местных, например халк негр Девид. В переписке вполне такой милый чел, я думал что это какой то ботаник а вот оказывается. Халк.

В амд есть уровни менеджмента и уже в 2012м было так: локально русские, выше в Канаде русские. Они приезжали. давно там живут. А дальше индус. Он тоже приезжал. Претензий нет но…

Так вот. Еще до команды закрыть офисы канадскую часть ядерных разработчиков уволили и отдали разработку в Бангалор. Это было еще хрен знает когда. Про техподдержку я вообще молчу потому что ты не можешь послать это чудище зачитывающее тебе текст с бумажки на непонятном языке заткнуться потому что ты уже решил проблему.

Индусский рак там давно. Индусы добравшись до руководящих позиций заменяют всех на индусов. Это известно.

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

вот и замечательно! читаем-набираем опыта! :о)

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