> Я не работал с амд на уровне допиливания прошивки (только на уровне
> драйвера), но сейчас занимаюсь этим для PowerVR.

А тут в топике про ARMовские дизайны, у них я вообще сервисных ядер так сразу не припоминаю как минимум у старых, просто конвееры для pixel/fragment shaders, еще и деление вычислителей по типам таскали до упора.

> Именно в самой прошивки и создаются различные кучи инстансов устройства
> (к счастью без виртуализации она всего одна) и MMU там нужен для наложения
> всего этого.

Ну вот как оно у PowerVR я не знаю, помню что на них народ плевался что это почти целиком firmware-based дизайн. Он возможно даже амд в этом переплюнул. И я не совсем понимаю как такой дизайн дружественно опенсорцу забацать, если вообще все на здоровенной фирмваре держится. Какие у этих господ планы на этот счет? Я так понимаю что с таким дизайном драйвер будет иметь чертову кучу лимитов что он (не)может без изменения фирмвары. А она так и будет проприетарная же, нет?

> Предположил, что Mali +- одного класса устройства как PowerVR блоки, поэтому предположил,
> что и в прошивки это все реализовано.

У как минимум старых MALI я вообще никаких прошивок не припоминаю, у самых новых может что и пропустил, не смотрел самые новые.

> Сейчас зашел в реализацию panfrost и там действительно mmu на уровне драйвера
> работает (CPU), был не прав (ARM, получается, не осилили?)

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

> atombios взял, потому что: у них довольная солидная таблица команд, для управления
> микрухи (ну и прошивки которая крутится на ней) и по коду
> становится понятно, что там отдельный управляющий блок с отдельной rtos.

Там несколько сервисных процессоров есть. Но как я понимаю в конечном итоге драйвре команды в очередь кидает и немало действа и сам код основной части GPU устраивает (в том числе и работу с его MMU?) а сервисные процы заведуют больше вспомогаловкой. Ну скажем SMU - заведует DVFS и вентилями, насколько я помню. Фирмварь этому вообще снаружи догружают при переходе в нативный режим, там же и сетап интересных таблиц, которые могут вообще перекрыть VBIOS - OEMы любят вписывать в таблицы какую-то жесть, потом нашлепав этого жутко жалеют о содеяном и вот амд придумало для этих неудачников вбивать оверрайды в драйвер. Но я смотрел относительно поверхностно, меня в драйвере сильно некоторые баги интересовали, в основном в районе того что они с контроллером памяти делают и SMU по части вольтажей-частот.

> В PowerVR там проще: настройка pagetable'ов как раз для MMU (по факту
> pool dma памяти передается по регистрам), наложение прошивки на heap устройства
> и, собственно, отправка адреса на начало boot секции в регистр.

Простите, а MMU - чьего для начала? ARM'а? GPU? Они в PowerVR делят 1 на 2, или чего? У амд то есть MMU со стороны GPU, и даже GPU-side paging. Есть адреса и страницы - в терминах GPU, x86 про это вообще ничего не знает, кроме как драйвер видяхи. В этом плане AMD GPU по сути отдельный комп на шине. А еще IOMMU есть, он доступы железа арбитрирует, и когда разговор про MMU неплохо уточнять какого из и как это все работает. Как видите там довольно по разному бывает и вот что что а у ARM врядли есть paging на стороне GPU c адресами и страницами GPU, они не настолько разогнались чтобы по сути отдельный комп сделать.

> Написал, что был не прав. Но вообще, свой MMU есть не только
> у дискретных карт, причем это далеко не новая технология. Интересно почему так.

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

>> Основная фича ускорителя в основном куча SIMD-образных крушилок.
> Очень сильное упрощение. Можно прировнять будет, только тогда, когда останется mesh-шейдеры
> с трассировкой лучей (при том, что аппаратный тайлинг никуда не делся).

GPGPU compute только вон тем и пользуется например. На трассировку лучей там кстати похрен.

> (спойлер: этапов там больше, чем описаны в спеках OGL/Vulkan) с хитрым
> аппаратным растеризатором (ну и аппаратным тайлингом) + аппаратный (де)кодировщик.

Ээээ там же и декодер видео? А то обычно это отделный IP блок, вообще не связанный с вон тем. Скажем у allwinner или rockchip это 100% отдельные блоки, никак вообще с сабжем не связанные.

А пересекаются они хоть как-то разве что в Display Controller по вопросам кто в какой surface рисует и что в сумме на экран будет. В этом плане у них всех есть нечто общее: у почти всех есть некие хардварные оверлеи/слои, в основном для вывода видео за хардварным декодером как раз. При том Display Controller так то тоже отделные железки, это только в десктопных в 1 железку универсально встроено, а у ARM это независимая железка. Дизайн KMS/DRM с неких пор учел такое деление выделив render nodes vs compute nodes. И оно могет жить с вот этим, когда может быть долбилка на экран без считалок, считалка без вывода на экран, или какое-то комбо первого и второго. Так и вон то представимо, и dGPU, и даже акселераторы безголовые. Да что там вон Habana вообще NPU но тоже хочет это все юзать, потому что для счета инфраструктура и им катит в принципе.

> И чтобы это все быстро выключалось, а также быстро включалось (дабы экономить батарею).

У амд довольно забавные технологии на этот счет, но я смотрел только относительно старые, без наворотов типа BACO (bus active chip off) и проч. А так там сервисный процик очень шустро менеджит DVFS по нагрузке, со временем его даже научили в овердрафт уходить, когда можно кратковременно шпарить более чем долговременно выдерживаемый режим, но если продолжается, то снизить клок до долговременно перевариваемого, и тому подобные вещи. Но они больше на перфоманс ориентированы.

> Поэтому набрать самый большой FLOPS не является приоритетной задачей. Нейронку тебе
> на мобильном GPU никто не будет запускать, для этого есть VPU/NPU блок

Ну на мелочи это не развито. И там так то забавные TOPS иногда бывают у этих штук :)

> (может сразу в камере, поэтому многие хуже работают без сладких
> блобов в LineageOS том же).

Камера никак не поможет для других применений VPU/NPU, так что это туповатый дизайн имхо.

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

Ээээ.... нельзя ли поподробнее на этот счет?