Войти
ПрограммированиеФорум2D графика и изометрия

Зачем нужен padding в данных битмапа?

Страницы: 1 2 3 Следующая »
#0
(Правка: 12:38) 12:37, 11 сен. 2021

Я видел в коде freetype2 и в плагинах на эмулятор сеги такую вещь как padding, это когда строки картинки выровнены по какому-то числу и физически на них уходит больше данных чем на то, что видит человек, то есть width картинки меньше чем выделено данных на строку изображения. Какой в этом профит? Ведь больше данных и копировать дольше и каждый раз этот отступ перепрыгивать через заранее высчитанный pitch, эти пиксели в padding области всё равно не видно. Кажется будто это сделано для производительности, мол каждая строка выровнена в памяти, но мне кажется что это только кэш ерундой забивает. Я видел реализацию копирования области картинки через вызов memcpy для каждой строки, так вот эта реализация даже медленнее обычного цикла... Объясните зачем набивать картинку лишними данными, которые не видно?


#1
13:15, 11 сен. 2021

Я не знаю точного ответа, но многие графические форматы уходят корнями в ранние девяностые, а то и вообще в поздние восьмидесятые. Windows 3, OpenGL 1.1 и иже с ними.
А потом от фичи уже не избавишься, она проросла во всё и приходится её тащить ради совместимости.
Плюс, ARM архитектура очень не дружит с невыровненными данными, а возможно - и многие видяхи ранних 2000-х тоже. И тогда загрузка текстуры быстрее, и поддержка нужна, и зомби продолжает ковылять.

#2
13:23, 11 сен. 2021


Еще невидимый отступ вокруг глифа делается для того, что бы не было косяков при фильтрации текстуры.

#3
14:00, 11 сен. 2021

HPW-Dev
> Какой в этом профит?
Не используй bmp. Он не слишком много памяти хавает. Уже давно придумано много форматов получше без потери информации.

#4
14:02, 11 сен. 2021

HPW-Dev
> но мне кажется что это только кэш ерундой забивает.
Ты походу не застал времена, когда скорость процессора была гораздо ниже скорости памяти.

#5
14:48, 11 сен. 2021

samrrr
>Не используй bmp
Я не использую, у меня в проекте пиксели в одномерном массиве без этих отступов, но почему так сделано в других программах? Возможно в эмуляторе сеги padding есть только для имитации передачи ТВ сигнала, мол там тоже был отступ для HSync и видимо для совместимости оставили отступы, но это не точно

#6
(Правка: 14:54) 14:54, 11 сен. 2021

samrrr
> скорость процессора была гораздо ниже скорости памяти
Получается что сейчас выравнивание начала данных картинки и выравнивание начала каждой строки не даст прироста на современных процах?

#7
17:00, 11 сен. 2021

HPW-Dev
> Кажется будто это сделано для производительности, мол каждая строка выровнена в памяти, но мне кажется что это только кэш ерундой забивает. Я видел реализацию копирования области картинки через вызов memcpy для каждой строки, так вот эта реализация даже медленнее обычного цикла...
> Получается что сейчас выравнивание начала данных картинки и выравнивание начала каждой строки не даст прироста на современных процах?
Там много факторов.
Пример:
https://rextester.com/DDDO21482
Походу, компилятор оптимизирует memcpy с известным на этапе компиляции размером. И оптимизирует неудачно, и библиотечная версия в 2 раза быстрее.
Здесь padding примерно на 7% быстрее, чем без.

Ну, на диске padding'у, ИМХО, всё-равно не место.

#8
18:42, 11 сен. 2021

HPW-Dev
> Получается что сейчас выравнивание начала данных картинки и выравнивание начала
> каждой строки не даст прироста на современных процах?
Если коротко, то скорее всего не даст.

FordPerfect
> Пример:
> https://rextester.com/DDDO21482
Так и не понял что такой тест может показать.

#9
23:45, 11 сен. 2021

samrrr
> Так и не понял что такой тест может показать.
Ну например, что всякое
> Я видел реализацию копирования области картинки через вызов memcpy для каждой строки, так вот эта реализация даже медленнее обычного цикла...
оно зачастую не про железо, а про чудеса memcpy.

#10
(Правка: 7:03) 7:03, 12 сен. 2021

Для векторных инструкций обычно желательно выравнивание.

#11
10:26, 12 сен. 2021

Ещё padding может от cache aliasing помогать.
Только там целевой размер предположительно некруглый.

#12
11:01, 12 сен. 2021

}:+()___ [Smile]
> Для векторных инструкций обычно желательно выравнивание.
Однко насколько часто это осмысленно для обработки изображений?
1. Если мы что-то блитим по рандомным координатам - выравнивание строк не факт, что влияет (если у нас гранулярность пикселей, а не блоков пикселей).
2. Даже если мы, например, всегда работаем со строками целиком - не факт. Вон в #7 особой разницы не заметно (а та, которая есть - вероятно из-за того, что круглый размер копируется за меньшее количество инструкций, а не из-за выравнивания). Возможно у меня кривой тест, так мне интересен пример более правильного.

Кстати невыровненныя копирования - они на x86  всегда медленнее, или только когда пересекают cache line?

#13
11:45, 12 сен. 2021

FordPerfect
> Если мы что-то блитим по рандомным координатам - выравнивание строк не факт, что влияет
У нас два чтения и одна запись — как минимум часть можно сделать выровненными.

> Даже если мы, например, всегда работаем со строками целиком - не факт.
На чистом ассемблерном коде разница заметна. В #7 это больше приколы компилятора и реализации memcpy.

> Кстати невыровненныя копирования - они на x86 всегда медленнее, или только когда пересекают cache line?
Когда пересекают — всегда медленней, иначе могут быть варианты. Зависит от того, пожалели ли транзисторов на это при разработке процессора. Вроде у всех современных процессоров доступ к выровненным данным примерно одинаков, однако раньше был штраф просто за само использование инструкции невыровненного доступа. Еще надо учесть, что часть инструкций требует выровненных данных. При использовании там невыровненных эту инструкцию надо разбивать на несколько с потенциальным расходом дополнительного регистра, что тоже может влиять отрицательно на производительность.

#14
14:18, 12 сен. 2021

Здесь предполагают, что на старых процессорах выравнивание влияло.
https://stackoverflow.com/questions/2185944/why-must-stride-in-th… multiple-of-4
Наверное, так и есть - легаси с древних времён.
Но вообще это не самая удивительная вещь в виндовых битмапах. Хранение данных вверх ногами никого не смущает? А цветовые компоненты как BGR вместо RGB?

Страницы: 1 2 3 Следующая »
ПрограммированиеФорум2D графика и изометрия