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

[Alexey Sheplyakov]

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

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

> 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.

Наш выбор 1). И нам нужно поддерживать не только Baikal-M (но и rk3399,
например), поэтому никаких "affinity &= f"

> > Раньше (по незнанию) использовали обе группы шейдерных ядер, что вызывало
> > периодические зависания GPU. Теперь разобрались, и используем только первую
> > группу шейдерных ядер. Зависания GPU прекратились, но FPS теперь в 2 раза меньше, да.

> Вообще-то патчу с "affinity" уже скоро два года. И ничего не зависает.

Прекрасно зависает, падает, дёргается. Например вот так:
https://bugzilla.altlinux.org/40051
Надо просто кроме glmark запустить что-нибудь ещё (использующее GL),
например chromium, и немного подождать

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