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

[Vadim V. Vlasov]

Приветствую!

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, и немного подождать

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

Вадим.

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