Mesa 24.2 с новой реализацией кэша шейдеров

Картинка как замечательно смотрится. В теме tango Как родная.

Новая реализация кэша шейдеров. Mesa 24.2 теперь использует новую реализацию кэша шейдеров по умолчанию. Это изменение направлено на уменьшение нагрузки на файловую систему и улучшение производительности.

Интересно что сделали, а на деле ~/.cache/mesa_shader_cache монтируется в tmpfs или через перемеренную окружения перенаправляется на каталог в tmpfs уже существующей и никакой нагрузки на диски, кушаем оперативку.

В любом случае mesa и игорь верхом на ней скачут бодро, пусть себе скакает лошадка, таща за собой повозку с моторчиком из линукса в светлое будущее.

игорь рулит!

а на деле ~/.cache/mesa_shader_cache монтируется в tmpfs или через перемеренную окружения перенаправляется на каталог в tmpfs

Хех, ну для меня это никаких изменений тогда, потому что у меня ~/.cache целиком в tmpfs примонтировано и так.

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

никакой нагрузки на диски

Так а чем это лучше в конечном итоге? Что, там 28мб проблематично читать с диска?

Никак, шейдеры пишут разработчики, вот например код шейдера и его работа

• https://www.shadertoy.com/view/lfscD7

Если ты откроешь в браузере и увидишь анимацию значит, mesa скомпилировала шайдер для твоей видеокарты, и закешировала результат в каталоге кеша шейдеров, если ты завтра откроешь эту же страницу и хеш текста не поменялся то компиляции не будет, а оно просто возьмётся из кэша. Как браузер кеширует всякое из интерента чтобы по 100 раз не загружать и декодировать одно и тоже, так и mesa делает. Этот же код что по ссылке ты в транслированном но ещё коде glsl можешь найти у себя в системе в кэше ну и ив скомпилированном виде для загрузки в вычислительные блоки видеокарты тоже можешь найти

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

Иногда шейдеры генерируется на лету, одни при этом выгружаются, другие загружаются, в интерактивной графике это буквально видно глазами, поддёргивания и прочая синхронизация. Современные игры вообще могут по несколько минут «зависать» в ожидании когда там всё будет готово. Варианты разные, размазывать работу с подготовкой шейдеров на процесс работы интеранктивной графики ну и иногда затупки ловить на моментах обновления «прошивки» карточки, или перед стартом всё подготавливать в моменте загрузки, иногда надо одно, иногда другое, но так или иначе если нужно сменить шейдер, то его нужно загрузить, а это IO операция в любом случае (почти любом). Иногда имеет смысл вообще вырубить кеширование шейдеров так как их динамическая обработка идёт быстрее чем взятие с диска. Вот и всё. Чаще всего это всё не страшно, это проблема всяких анриалов и прочих жиробасов с тысячами шейдереных программ, которые туда сюда, загружаются выгружаются как бешенные и на компиляцию ещё уходит хренова туча времени.

Но в целом, когда так. У кого 28 мегабайт, а у кого 280+. Усугубляется всё ещё тем что кеш это тучка мелких файликов (был раньше сейчас не знаю как)

Новая реализация кэша шейдеров. Mesa 24.2 теперь использует новую реализацию кэша шейдеров по умолчанию. Это изменение направлено на уменьшение нагрузки на файловую систему и улучшение производительности.

а в реальности вот что:

$ cd ${XDG_CACHE_HOME}/mesa_shader_cache_db
$ tree
.
├── index
├── marker
├── part0
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part1
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part10
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part11
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part12
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part13
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part14
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part15
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part16
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part17
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part18
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part19
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part2
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part20
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part21
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part22
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part23
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part24
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part25
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part26
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part27
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part28
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part29
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part3
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part30
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part31
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part32
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part33
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part34
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part35
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part36
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part37
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part38
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part39
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part4
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part40
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part41
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part42
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part43
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part44
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part45
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part46
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part47
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part48
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part49
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part5
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part6
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part7
│   ├── mesa_cache.db
│   └── mesa_cache.idx
├── part8
│   ├── mesa_cache.db
│   └── mesa_cache.idx
└── part9
    ├── mesa_cache.db
    └── mesa_cache.idx

51 directories, 102 files

По умолчанию включён новый тип кэша шейдеров - Mesa-DB, сохраняющий данные в ОДНОМ ФАЙЛЕ, что позволяет снизить нагрузку на файловую систему.

Ну, раньше было иначе — аж вот так: https://privatebin.net/?9dd43c2b620834b8#4HsC8Enhks3W3bnyEpZ1NFEeuC9vrhnwBWz9irncA8A7

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

По умолчанию включён новый тип кэша шейдеров - Mesa-DB, сохраняющий данные в ОДНОМ ФАЙЛЕ,

а в реальности вот что:

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

спасибо, помогло

$ echo $MESA_DISK_CACHE_DATABASE_NUM_PARTS
1
$ cd ${XDG_CACHE_HOME}/mesa_shader_cache_db
$ tree
.
├── index
├── marker
└── part0
    ├── mesa_cache.db
    └── mesa_cache.idx

2 directories, 4 files

Статтеры во время каждой перекомпиляции не мучают?

Годно, ждем пкгбилдов. Посмотрим, насколько ускорится подгрузка шейдеров из кэша, если ускорится вообще. Еще я жду патч для низкой задержки кодирования видео на карточках AMD. Он позволяет выставить переменную окружения AMD_DEBUG=lowlatencyenc и стримить игры через Sunshine без статтеров и лагов.

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

Все так, поэтому режим низкой задержки не включен по умолчанию, а активируется отладочной переменной только в нужных приложениях. Я замерял задержку при стриминге в 4K @ 60 фпс. Без флага lowlatencyenc были постоянные статтеры каждые несколько секунд, а время кодирования некоторых кадров подпрыгивало до 40 мс. С этим флагом все работает намного лучше, а время кодирования кадров почти всегда укладывается в 15-16 мс.

Отличные новости, как раз 16 числа обновился.

Алсо, на всякий

${XDG_CACHE_HOME}/mesa_shader_cache_db

Есть MESA_SHADER_CACHE_DIR.

В смысле из-за удаления при перезагрузке, примерно раз в месяц? Да нет, как-то даже не замечаю практически.

По умолчанию эта переманная не задана. Её можно задать, чтоб другую директорию использовать, но у него же по умолчанию, значит не сработает с cd.

Её можно задать, чтоб другую директорию использовать

Для этого и упомянуто. Переносить целиком XDG_CACHE_HOME не всегда хорошая идея - там могут быть закэшированные данные из интернета, к примеру.

ls .cache/ | grep mesa
mesa_shader_cache
mesa_shader_cache_db

Так что, каталог mesa_shader_cache пора сносить? Там не то чтоб много 465,9 МиБ, 154348 files, 257 folders, но там есть файлы датирующиеся аж 19 годом, хотя сам каталог создан в 2022 и ни разу не сносился\чистился руками.

Що там з nouveau?

Сноси, все равно при каждом обновлении Mesa те шейдеры, которые уже лежат в кэше, теряют актуальность. Кэш шейдеров зависит от версии видеодрайвера.

Какая-то явно сгенерированная из release notes новость. Просто бездумная суммаризация. К примеру OpenGL 4.6 поддерживается с Mesa 19.3, а в release notes она упоминается каждый раз, и в результате получаем это в «Основных изменениях и улучшениях «

Я пока что с ним игарю, но так и не смог побороть скачки битрейта на i-фреймах. Наверно нужно полностью заменить на infra-refresh их, но это сложно. wifi подключение не вывозит скачёк битрейта и подскакивает задержка, кадры пропускаются, плавность стриминга vr на шлем страдает. В В остальном когда задержка на 30мс меньше это конечно сильно помогает

Если ты откроешь в браузере и увидишь анимацию значит

Блин, у меня там просто черная картинка :(

У меня после включения webgl2 всё работает. Без webgl2 чёрная картинка

Ужас, это в рам засунуть, то в рам засунуть. Скоро под «в рам засунуть» надо отдельно 64Гб брать :)

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

• https://thebookofshaders.com/edit.php поиграться можно
• https://glslsandbox.com/ так просто примеры

Опять же это не какая то браузерная фича.

Не, тут как бы по потребностям, рама не то и рама чтобы в неё совать. Всё не надо, запример ты играешь в 1 любимую игру, для mesa через перемеренную окружения при запуске этой игры указал альтернативный каталог для кеша который для неё и только для неё в оперативке и всё. А остальное по обычному работает, ну это в случае когда игрушку ком тянет то не очень и убрать лишние микрофризы за бесплатно можно пожертвовав дополнительно парой десятков (или сотен) мегабайт. Вот и всё. Это в работе надо тонну рамы для оптимизации работы кучи открытых программ и фоновых процессов, а дома то, дома ненужное в данный момент можно и позакрывать, освободив и вычислительные ресурсы и память для более приоритетной в данный момент задачки. Вот и всё. Те кто могут себе позволит 64 и 128 гигов оперативки, нормальной оперативки, так и делают, закупят и в ус не дуют, но это пренебрежительное меньшинство и можно на их существование вообще не обращать внимание и распределять домашние вычислительные ресурсы просто более бережно, вот и всё.

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

Программа может работать быстро либо сжирая память, либо сжирая время ЦПУ, что выгоднее зависит от случая. Тут как бы… что поделать.

Тьфу, опять меня пробило на графоманство. Нутыпонял крч мои мысли :D

О, а тут все работает. Хм. Ну ок, разберусь.

Здесь все работает, что самое интересное:

https://thebookofshaders.com/edit.php

https://glslsandbox.com/

Пишут вроде, что надо принудительно включить webgl2 в настройках фокса, но у меня оно включено, ничего не трогал. Только вот аппаратное ускорение отключено, не знаю, влияет ли.

но это пренебрежительное меньшинство и можно на их существование вообще не обращать внимание

Афигеть. Сижу, никого не трогаю и тут мне сообщают что мною можно пренебречь и вообще внимание не обращать…

Лучше поздно, чем никогда.

:) Ну ты на личный счёт то не воспринимай хехе, просто когда например говорят про массовую диспансеризацию населения, тех кто может позволить себе элитную клинику для этого в любой момент в расчёт не берут, так и тут. =) Был бы разговор о например продаже/создании/поддержке тяжеловесного софта для рабочих тачек (пусть и домашних) был бы другой разговор хехе

P.S. Ты про «починяю примус» забыл :)

у меня вообще не firefox, webgl2 был выключен из-за проблем на 2gis (не актуально, насколько мне известно), и на странице по ссылке включение его обратно помогло, 2gis не сломался, видимо что-то поправили

Позно, я уже принял 😂

Хоспадибожемой, споил человека, довёл до синьки. Эх я. :D

Ужас, это в рам засунуть, то в рам засунуть.

Ало, у меня за несколько лет в кеше меньше 500МиБ собралось. Такой объем, что пренебречь. 16 рам сейчас минималка для десктопа\ноутбука.

При светлой теме рисунок нечитаемый.

за несколько лет

Удали, там 99% уже мусор

Ужас, это в рам засунуть, то в рам засунуть. Скоро под «в рам засунуть» надо отдельно 64Гб брать :)

В смысле «скоро»? У меня в личном лаптопе 64 уже года 4 наверное, рабочие выдают с 64, в десктопе вообще 128…

640 гигабайт хватит всем

Я имел ввиду отдельно от всего 64гб рам под кэш

Я имел ввиду отдельно от всего 64гб рам под кэш

Жду, когда мы избавимся от атавизма с разделением на ОЗУ и ПЗУ. Правда для того, чтобы это имело смысл, надо ОС с новой парадигмой.