[Arm64-baikalm] Регресс в ядре 5.15

[Alexey Sheplyakov]

Здравствуйте!

On Thu, Jul 07, 2022 at 02:38:16PM +0300, Vadim V. Vlasov wrote:
> Приветствую!
> 
> On 7/6/22 5:34 PM, Alexey Sheplyakov wrote:
> > Здравствуйте!
> > 
> > On Wed, Jul 06, 2022 at 03:48:41PM +0300, Vadim V. Vlasov wrote:
> > > A. Собираем ядро baikalm-5.15.y-next, запускаем "glmark2 --annotate",
> > > получаем общий результат 210.
> > > 
> > > B. Идем в panfrost_job_write_affinity() (panfrost_job.c) принудительно
> > > вырубаем все ядра кроме 4-х (affinity &= 0xf;). Вроде, ничего не должно
> > > поменяться. Запускаем glmark2 - получаем 204 (отклонение в пределах
> > > погрешности).
> > Утверждение неверное. Сломали T7xy, T8xy с > 4 шейдерных ядер.
> > Можно сделать более аккуратно - проверить, сколько групп когерентности,
> > и подкрутить affinity, и тогда да - ничего не изменится.
> Я, вроде, не предлагал в таком виде заапстримить. Просто хотел точно указать
> то место, где теряется почти половина производительности.
> > Изначально я так и сделал [1], но в итоге приняли патч, где 2ю группу
> > ядер просто отключают.
> > 
> > https://lists.freedesktop.org/archives/dri-devel/2021-December/335738.html
> > 
> Странный патч... Альтернативная affinity применяется для js=2, который в
> драйвере не используется.
> > > C. Идем в panfrost_gpu_power_on() и убираем core_mask: "core_mask =
> > > pfdev->features.shader_present;" перед записью в SHADER_PWRON_LO. glmark2 =
> > > 201 - ничего не изменилось.
> > Не факт. Теоретически если не включать вторую группу ядер, то будет
> > меньше потребление энергии (хотя я не уверен, что у Baikal-M есть
> > соответствующий power gating).
> Теоретически, если ядро ничего не делает, то оно и потреблять почти не
> должно.
> > 
> > > D. Снова идем в panfrost_job_write_affinity() и перед строчкой из п."B"
> > > добавляем условие:
> > > 
> > > if (js == 1)
> > js == 1 -- это вертексные шейдеры. И они действительно должны выполняться
> > на первой группе ядер. Это необходимо, но не достаточно!
> > 
> > 1) Перед запуском вершинных шейдеров после выполнения фрагментных шейдеров
> >     на обоих группах ядер требуется cache flush. panfrost пока этого не
> >     умеет, и Ваш патч не обрабатывает такую ситуацию.
> > 
> > 2) В некоторых случаях фрагментным шейдерам тоже нужна когерентность.
> >     Ваш патч этого не обрабатывает.
> > 
> > 3) Hardware gets upset if the affinity masks for slot 0 and slot 1 overlap.
> >     Нужно доработать планировщик так, чтобы фрагментные шейдеры (js 0),
> >     которые используют ядра из 2й группы либо ожидали завершения всех
> >     вертексных (и геометрических) шейдеров, либо фрагментные шейдеры
> >     при этом запускались только во 2й группе, и в нужных местах делали
> >     Ничего этого Ваш патч не делает.
> > 
> > > Получаем glmark2 = 377 - почти вдвое больше.
> > И артефакты и зависания "на ровном месте".
> > 
> > > E. Осталось полностью откатить обсуждаемый патч (включить второй кластер
> > > L2-кэша)
> > Осталось "всего лишь" разобраться, как блоб решает описанные выше проблемы,
> > и допилить ядро и Mesa.
> > 
> > А до этого прекрасного времени есть выбор:
> > 
> > 1) Используем только 4 шейдерных ядра. Получаем стабильность.
> > 2) Делаем вид, что достаточно вертексные шейдеры на первой группе ядер.
> >     Получаем артефакты и зависания, и в 2 раза больше попугаев в glmark.
> Этот выбор можно было бы сделать на уровне kernel commandline.
> > Наш выбор 1). И нам нужно поддерживать не только Baikal-M (но и rk3399,
> > например), поэтому никаких "affinity &= f"
> Если не путаю, в rk стоит mali t7xx, которому этот патч не нужен.
> > > > Раньше (по незнанию) использовали обе группы шейдерных ядер, что вызывало
> > > > периодические зависания GPU. Теперь разобрались, и используем только первую
> > > > группу шейдерных ядер. Зависания GPU прекратились, но FPS теперь в 2 раза меньше, да.
> > > Вообще-то патчу с "affinity" уже скоро два года. И ничего не зависает.
> > Прекрасно зависает, падает, дёргается. Например вот так:
> > https://bugzilla.altlinux.org/40051
> Неудачный пример - это совсем другая ошибка в драйвере.
> > Надо просто кроме glmark запустить что-нибудь ещё (использующее GL),
> > например chromium, и немного подождать


Подведу итог.

Вы хотите задействовать все шейдерные ядра. И утверждаете, что для
этого достаточно вершинные (и геометрические) шейдеры запускать только
на первой группе ядер. И при этом GPU будет корректно работать, без
зависаний и артефактов.

С этими утверждениями я категорически не согласен, как на основании
собственных наблюдений [1], так и на основании того, что рассказали
знающие люди [2], и что я накопал в mali_kbase.

[1] После отключения второй группы шейдерных ядер зависания GPU стали
    намного реже (за полгода - ни разу)
[2] https://lists.freedesktop.org/archives/dri-devel/2022-January/336701.html

Как правильно задействовать вторую группу шейдерных ядер - я пока не знаю.
Рисковать стабильностью системы ради удвоения попугаев в glmark я не готов.
Теста, который бы с 100% вероятностью за разумное время показал, что
Вы не правы, у меня пока нет, к сожалению.

На этом разрешите откланяться, и больше не участвовать в обсуждении
особенностей T628 (и соответствующего кода в panfrost).

> chromium вррбще не работает даже на ядре 5.15.29-51730-g01c2ae844980. А
> firefox с youtube и glmark2 вполне работают одновременно и без артефактов.

У меня всё работает (C), но если что - пишите в bugzilla.altlinux.org
(как именно не работает, работал ли когда-либо раньше, и т.п.),
постараюсь помочь разобраться.

Всего доброго,
    Алексей