Иногда соединяя одновременно 5 антиоптимизаций получаешь код в 3 раза быстрее.

Я долго бился с ускорением ML рендер техники. Но тренировка никак не получалась быстрее 4мс.

Я пробовал:
1. Развернуть циклы. Видимо слишком много регистров надо, стало медленее.
2. Саккумулировать данные со всех тредов волны прежде чем писать их через atomicAdd.
3. Аккумулировать по всей группе, а не по волне. Стало еще хуже без wave-instrinsic-ов
4. Вместо атомиков писать в отдельные слоты и суммировать позже. Еще чуть хуже.
5. Кооперативную обработку одного сэмпла несколькихи тредами. Вообще жуть.


Я попробовал все сразу. И войля. 1.3мс

Вот это вот и весь стенд с моей работой на AMD AI.
Ну может быть на ближайшей конфе по графике хоть расскажут

https://www.twitch.tv/randomrustdev

Первый стрим с кодингом на расте.
С места в карьер.
Разрабатывается Аркана.
Система импорта ассетов.

Сейчас начнется новый стрим.
Разработка импортера для картинок.
Ссылка та же

https://www.twitch.tv/videos/2277544249
Ссылка на запись стрима.
Я немного покосячил с окнами, но в целом получилось не так плохо, как мне кажется.

Сделали импортер для картинок, сделали UI для импорта, увидели, что что-то заимпортилось и получило AssetID.

Как вы думаете, на сколько надо подготавливаться заранее к стриму?

Я не имею в виду звук и настройку окон и вот это, что непосредственно стрим составляет. Это конечно надо все подготовить 🍳

Я про сам код. Я пробовал кодить с наскоку 🏇
Сегодня вот только убедился что создание плагина работает. Из-за чего эдитор перестал запускаться, когда я плагин удалил 🤦‍♂️
Но совершенно не продумывал как я буду писать. Только что.

На другом конце спектра будет ненастоящее программирование, а переписывание того, что уже написал заранее.

Как по вашему мнению, где золотая середина?

This issue got me puzzled.
What's the correct answer?

https://github.com/zakarumych/egui-snarl/issues/42

На стриме я реализовывал импортер картинок в базовый RGB, что в общем-то сильно неоптимально.

Поэтому время пришло для того что бы жать картинки.

Как известно, GPU нативно поддерживают блочные сжатые форматы.
Реализовал сжатие в BC1.
Очень простое.

GUI что бы видеть результаты.
Слева картинка из файла, справа она же пожатая и разжатая обратно.

Попробовал интегрировать texpresso.
Из минусов:
1. Какие-то белые пиксели.
2. Очень долго сжимает - на видео видно пролаг при нажатии на чекбокс.

Продолжаю работать над сжатием картинок.
Прочитал два папируса сегодня: по кодам Хаффмана и работы Лемпеля и Зива.
Буду использовать сжатие без потерь, что бы пожать блоки, выданные блочными сжимателями.
При чем таким образом, что бы разжать можно было эффективно на gpu

Реализовал компрессию блоков формата BC1 для экономии на IO.

BC1 size: 362952 - 354KiB
JKL size: 13151 - 12.8KiB

Если я нигде не накосячил, то очень даже неплохой такой результат.

Заменил байт-ориентированный выход из кромпрессора на бит-ориентированный.

И сразу результат.

Пришлось попотеть чуть, за то теперь у меня есть std::io::{Read, Write} врапперы, чтоб писать и читать битики

LZ78 -> LZW
873KiB -> 799KiB

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

В файл веса класть не надо. При декодировании она точно так же должна обучаться

Я кстати понял, почему трава такая несжимаемая.
Она в жипеге весит столько же, сколько bc1, там энтропия чуть ли максимальная.

Просили больше нейронок? Получайте!

На видео микронейронка учится предсказывать картинку по соседям.

Цвета всех блоков на 3й картинке предсказаны нейронкой на основе соседей слева и сверху.
А точнее на входе квадрат 4х4 без правого-нижнего, а на выходе собственно правый-нижний.