Сжатие блоков (Direct3D 10)

Сжатие блоков — это метод сжатия текстур для уменьшения размера текстуры. По сравнению с текстурой с 32-разрядными на цвет, блочная сжимаемая текстура может быть до 75 процентов меньше. Приложения обычно видят увеличение производительности при использовании сжатия блоков из-за меньшего объема памяти.

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

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

• Как работает сжатие блоков?
  • Хранение несжатых данных
  • Хранение сжатых данных
• Использование сжатия блоков
  • Виртуальный размер и физический размер
• Алгоритмы сжатия
  • BC1
  • BC2
  • BC3
  • BC4
  • BC5
• Преобразование формата с помощью Direct3D 10.1
• Связанные статьи

Как работает сжатие блоков?

Сжатие блоков — это способ уменьшения объема памяти, необходимого для хранения цветовых данных. Сохраняя некоторые цвета в исходном размере и других цветах с помощью схемы кодирования, вы можете значительно уменьшить объем памяти, необходимой для хранения изображения. Так как оборудование автоматически декодирует сжатые данные, производительность за использование сжатых текстур отсутствует.

Чтобы узнать, как работает сжатие, ознакомьтесь со следующими двумя примерами. В первом примере описывается объем памяти, используемый при хранении несжатых данных; второй пример описывает объем памяти, используемой при хранении сжатых данных.

Хранение несжатых данных

На следующем рисунке представлена несжатая текстура 4×4. Предположим, что каждый цвет содержит один цвет (красный для экземпляра) и хранится в одном байте памяти.

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

Хранение сжатых данных

Теперь, когда вы узнали, сколько памяти использует несжатый образ, посмотрите, сколько памяти сохраняет сжатый образ. Формат сжатия BC4 хранит 2 цвета (1 байт каждый) и 16 3-разрядных индексов (48 битов или 6 байтов), которые используются для интерполяции исходных цветов в текстуре, как показано на следующем рисунке.

Общее пространство, необходимое для хранения сжатых данных, составляет 8 байт, что является 50-процентной экономией памяти по сравнению с несжатым примером. Экономия даже больше, если используется несколько цветового компонента.

Существенное экономия памяти, предоставляемая сжатием блоков, может привести к увеличению производительности. Эта производительность приходится на стоимость качества изображения (из-за интерполяции цвета); однако более низкое качество часто не заметно.

В следующем разделе показано, как Direct3D 10 упрощает использование сжатия блоков в приложении.

Использование сжатия блоков

Создайте блочное сжатие текстуры так же, как несжатую текстуру (см. раздел "Создание текстуры из файла"), за исключением того, что вы указываете формат, сжатый блоком.

loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);

Затем создайте представление для привязки текстуры к конвейеру. Так как текстура сжатой блоком может использоваться только в качестве входных данных на стадии шейдера, необходимо создать представление ресурсов шейдера, вызвав CreateShaderResourceView.

Используйте сжатые блоки текстуры так же, как и несжатую текстуру. Если приложение получит указатель памяти на блочные сжатые данные, необходимо учитывать заполнение памяти в MIP-карте, что приводит к отличию объявленного размера от фактического размера.

Виртуальный размер и физический размер

Если у вас есть код приложения, использующий указатель памяти для обхода памяти сжатой текстуры блока, важно учитывать одно важное соображение, которое может потребовать изменения в коде приложения. Блочное сжатие текстуры должно быть кратным 4 во всех измерениях, так как алгоритмы сжатия блоков блочного сжатия работают с 4x4 блоками текселя. Это будет проблемой для MIP-карты, начальные измерения которых делятся на 4, но разделенные уровни не являются. На следующей схеме показано различие между размером виртуальной (объявленной) и физическим (фактическим) размером каждого уровня MIP-карты.

В левой части схемы показаны размеры уровня MIP-карты, созданные для несжатой текстуры 60×40. Размер верхнего уровня берется из вызова API, создающего текстуру; каждый последующий уровень составляет половину размера предыдущего уровня. Для несжатой текстуры нет разницы между размером виртуальной (объявленной) и физическим (фактическим) размером.

В правой части схемы показаны размеры уровней MIP-карты, созданные для той же текстуры 60×40 с сжатием. Обратите внимание, что на втором и третьем уровнях есть заполнение памяти, чтобы сделать размеры 4 на каждом уровне. Это необходимо, чтобы алгоритмы могли работать с 4×4 блоками текселя. Это особенно очевидно при рассмотрении уровней mipmap, которые меньше 4×4; Размер этих очень небольших уровней MIP-карты округляется до ближайшего коэффициента 4 при выделении памяти текстуры.

Оборудование выборки использует виртуальный размер; При выборке текстуры не учитывается заполнение памяти. Для уровней mipmap, которые меньше 4×4, для карты 2×2 будет использоваться только первые четыре текселя, и только первый тексель будет использоваться блоком 1×1. Однако нет структуры API, которая предоставляет физический размер (включая заполнение памяти).

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

Алгоритмы сжатия

Методы сжатия блоков в Direct3D разбивают несжатые данные текстуры на 4×4 блока, сжимают каждый блок, а затем хранят данные. По этой причине текстуры, которые, как ожидается, будут сжатыми, должны иметь размеры текстуры, кратные из 4.

На предыдущей схеме показана текстура, секционированная в блоки texel. Первый блок показывает макет 16 текселей, помеченных a-p, но каждый блок имеет одинаковую организацию данных.

Direct3D реализует несколько схем сжатия, каждая из которых реализует разные компромиссы между количеством хранимых компонентов, числом битов на компонент и объемом используемой памяти. Используйте эту таблицу, чтобы выбрать формат, который лучше всего подходит для типа данных и разрешения данных, подходящих для приложения.

BC1

Используйте первый формат сжатия блоков (BC1) (DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM или DXGI_BC1_UNORM_SRGB) для хранения трехкомпонентных данных цвета с использованием цвета 5:6:5 (5 бит красный, 6 бит зеленый, 5 бит синий). Это верно, даже если данные также содержат 1-разрядную альфа-версию. Предполагая, что текстура 4×4 с помощью максимального формата данных возможна, формат BC1 сокращает объем памяти, необходимый от 48 байт (16 цветов × 3 компонента или цвета × 1 байт/компонент) до 8 байт памяти.

Алгоритм работает на 4×4 блоках текселей. Вместо хранения 16 цветов алгоритм сохраняет 2 ссылочных цвета (color_0 и color_1) и 16 2-разрядных индексов цветов (блоки a–p), как показано на следующей схеме.

Индексы цветов (a–p) используются для поиска исходных цветов из таблицы цветов. Таблица цветов содержит 4 цвета. Первые два цвета — color_0 и color_1 — это минимальные и максимальные цвета. Остальные два цвета, color_2 и color_3, являются промежуточными цветами, вычисляемыми с помощью линейной интерполяции.

color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1

Четыре цвета назначаются 2-разрядным значениям индекса, которые будут сохранены в блоках a–p.

color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11

Наконец, каждый из цветов в блоках a–p сравнивается с четырьмя цветами в таблице цветов, а индекс для ближайшего цвета хранится в 2-разрядных блоках.

Этот алгоритм предоставляет себе данные, содержащие 1-разрядную альфа-версию. Единственное различие заключается в том, что color_3 имеет значение 0 (который представляет прозрачный цвет) и color_2 является линейной смесью color_0 и color_1.

color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;

Различия между Direct3D 9 и Direct3D 10:

Этот формат существует как в Direct3D 9, так и в 10.

• В Direct3D 9 формат BC1 называется D3DFMT_DXT1.
• В Direct3D 10 формат BC1 представлен DXGI_FORMAT_BC1_UNORM или DXGI_FORMAT_BC1_UNORM_SRGB.

BC2

Используйте формат BC2 (DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM или DXGI_BC2_UNORM_SRGB) для хранения данных, содержащих цветовые и альфа-данные с низкой степенью согласованности (используйте BC3 для высококонтентных альфа-данных). Формат BC2 сохраняет rgb-данные как цвет 5:6:5 (5 бит красный, 6 бит зеленый, 5 бит синий) и альфа в виде отдельного 4-разрядного значения. При условии, что текстура 4×4 с помощью максимального формата данных возможна, этот метод сжатия сокращает объем памяти, необходимый от 64 байт (16 цветов × 4 компонента или цвета × 1 байт/компонента) до 16 байт памяти.

Формат BC2 сохраняет цвета с таким же количеством битов и макета данных, что и формат BC1 . Однако bc2 требует дополнительных 64-разрядных объемов памяти для хранения альфа-данных, как показано на следующей схеме.

Различия между Direct3D 9 и Direct3D 10:

Этот формат существует как в Direct3D 9, так и в 10.

• В Direct3D 9 формат BC2 называется D3DFMT_DXT2 и D3DFMT_DXT3.

• В Direct3D 10 формат BC2 представлен DXGI_FORMAT_BC2_UNORM или DXGI_FORMAT_BC2_UNORM_SRGB

BC3

Используйте формат BC3 (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM или DXGI_BC3_UNORM_SRGB) для хранения данных цвета с высокой согласованности (используйте BC2 с менее последовательными альфа-данными). Формат BC3 сохраняет данные цвета с использованием цвета 5:6:5 (5 бит красных, 6 бит зеленых, 5 битов синего) и альфа-данных с использованием одного байта. При условии, что текстура 4×4 с помощью максимального формата данных возможна, этот метод сжатия сокращает объем памяти, необходимый от 64 байт (16 цветов × 4 компонента или цвета × 1 байт/компонента) до 16 байт памяти.

Формат BC3 сохраняет цвета с таким же количеством битов и макетом данных, что и формат BC1 . Однако bc3 требует дополнительных 64-разрядных объемов памяти для хранения альфа-данных. Формат BC3 обрабатывает альфа,сохраняя два ссылочных значения и интерполяируя между ними (аналогично тому, как BC1 сохраняет цвет RGB).

Алгоритм работает на 4×4 блоках текселей. Вместо хранения 16 альфа-значений алгоритм хранит 2 ссылочных альфа-символов (alpha_0 и alpha_1) и 16 3-разрядных индексов цвета (альфа-адрес через p), как показано на следующей схеме.

Формат BC3 использует альфа-индексы (a–p) для поиска исходных цветов из таблицы подстановки, содержащей 8 значений. Первые два значения — alpha_0 и alpha_1 — являются минимальными и максимальными значениями; остальные шесть промежуточных значений вычисляются с помощью линейной интерполяции.

Алгоритм определяет количество интерполированных альфа-значений путем изучения двух ссылочных альфа-значений. Если alpha_0 больше alpha_1, BC3 интерполирует 6 альфа-значений; в противном случае он интерполирует 4. Если BC3 интерполирует только 4 альфа-значения, он задает два дополнительных альфа-значения (0 для полностью прозрачного и 255 для полной непрозрачности). BC3 сжимает альфа-значения в области 4×4 текселя, сохраняя битовый код, соответствующий интерполированным альфа-значениям, которые наиболее тесно соответствуют исходному альфа-значению для заданного текселя.

if( alpha_0 > alpha_1 )
{
  // 6 interpolated alpha values.
  alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010
  alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011
  alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100
  alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101
  alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110
  alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111
}
else
{
  // 4 interpolated alpha values.
  alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010
  alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011
  alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100
  alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101
  alpha_6 = 0;                         // bit code 110
  alpha_7 = 255;                       // bit code 111
}

Различия между Direct3D 9 и Direct3D 10:

• В Direct3D 9 формат BC3 называется D3DFMT_DXT4 и D3DFMT_DXT5.

• В Direct3D 10 формат BC3 представлен DXGI_FORMAT_BC3_UNORM или DXGI_FORMAT_BC3_UNORM_SRGB.

BC4

Используйте формат BC4 для хранения однокомпонентных данных цвета с использованием 8 бит для каждого цвета. В результате повышения точности (по сравнению с BC1) BC4 идеально подходит для хранения данных с плавающей запятой в диапазоне от [0 до 1], используя формат DXGI_FORMAT_BC4_UNORM и [-1 до +1], используя формат DXGI_FORMAT_BC4_SNORM. При условии, что текстура 4×4 с использованием максимального формата данных возможна, этот метод сжатия сокращает объем памяти, необходимый от 16 байт (16 цветов × 1 компонентов и цветов × 1 байт/компонента) до 8 байтов.

Алгоритм работает на 4×4 блоках текселей. Вместо хранения 16 цветов алгоритм сохраняет 2 ссылочных цвета (red_0 и red_1) и 16 3-разрядных индексов цветов (красный через красный p), как показано на следующей схеме.

Алгоритм использует 3-разрядные индексы для поиска цветов из таблицы цветов, содержащей 8 цветов. Первые два цвета — red_0 и red_1 — это минимальные и максимальные цвета. Алгоритм вычисляет оставшиеся цвета с помощью линейной интерполяции.

Алгоритм определяет количество интерполированных значений цвета путем изучения двух ссылочных значений. Если red_0 больше red_1, bc4 интерполирует 6 значений цветов; в противном случае он интерполирует 4. Если BC4 интерполирует только 4 значения цветов, он задает два дополнительных значения цвета (0,0f для полностью прозрачной и 1,0f для полной непрозрачности). BC4 сжимает альфа-значения в области 4×4 текселя, сохраняя битовый код, соответствующий интерполированным альфа-значениям, которые наиболее тесно соответствуют исходному альфа-значению для заданного текселя.

BC4_UNORM

Интерполяция данных с одним компонентом выполняется, как в следующем примере кода.

unsigned word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = 0.0f;                     // bit code 110
  red_7 = 1.0f;                     // bit code 111
}

Ссылочные цвета назначаются 3-разрядные индексы (000–111, так как имеются 8 значений), которые будут сохранены в блоках красным цветом через красный p во время сжатия.

BC4_SNORM

DXGI_FORMAT_BC4_SNORM точно так же, за исключением того, что данные кодируются в диапазоне SNORM и когда интерполируются 4 значения цвета. Интерполяция данных с одним компонентом выполняется, как в следующем примере кода.

signed word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = -1.0f;                     // bit code 110
  red_7 =  1.0f;                     // bit code 111
}

Ссылочные цвета назначаются 3-разрядные индексы (000–111, так как имеются 8 значений), которые будут сохранены в блоках красным цветом через красный p во время сжатия.

BC5

Используйте формат BC5 для хранения двухкомпонентных данных цвета с использованием 8 бит для каждого цвета. В результате повышения точности (по сравнению с BC1) BC5 идеально подходит для хранения данных с плавающей запятой в диапазоне от [0 до 1], используя формат DXGI_FORMAT_BC5_UNORM и [-1 до +1], используя формат DXGI_FORMAT_BC5_SNORM. При условии, что текстура 4×4 с использованием максимального формата данных возможна, этот метод сжатия сокращает объем памяти, необходимый от 32 байт (16 цветов × 2 компонента или цвета × 1 байт/компонента) до 16 байтов.

Алгоритм работает на 4×4 блоках текселей. Вместо хранения 16 цветов для обоих компонентов алгоритм сохраняет 2 ссылочных цвета для каждого компонента (red_0, red_1, green_0 и green_1) и 16 3-разрядных индексов цветов для каждого компонента (красный через красный p и зеленый цвет), как показано на следующей схеме.

Алгоритм использует 3-разрядные индексы для поиска цветов из таблицы цветов, содержащей 8 цветов. Первые два цвета — red_0 и red_1 (или green_0 и green_1) — это минимальные и максимальные цвета. Алгоритм вычисляет оставшиеся цвета с помощью линейной интерполяции.

Алгоритм определяет количество интерполированных значений цвета путем изучения двух ссылочных значений. Если red_0 больше red_1, BC5 интерполирует 6 значений цветов; в противном случае он интерполирует 4. Если BC5 интерполирует только 4 значения цвета, он задает оставшиеся два значения цвета в 0,0f и 1.0f.

• BC5_UNORM
• BC5_SNORM

BC5_UNORM

Интерполяция данных с одним компонентом выполняется, как в следующем примере кода. Вычисления для зеленых компонентов аналогичны.

unsigned word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = 0.0f;                     // bit code 110
  red_7 = 1.0f;                     // bit code 111
}

Ссылочные цвета назначаются 3-разрядные индексы (000–111, так как имеются 8 значений), которые будут сохранены в блоках красным цветом через красный p во время сжатия.

BC5_SNORM

DXGI_FORMAT_BC5_SNORM точно так же, за исключением того, что данные кодируются в диапазоне SNORM, а при интерполяции двух дополнительных значений — 1,0f и 1.0f. Интерполяция данных с одним компонентом выполняется, как в следующем примере кода. Вычисления для зеленых компонентов аналогичны.

signed word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = -1.0f;                    // bit code 110
  red_7 =  1.0f;                    // bit code 111
}

Ссылочные цвета назначаются 3-разрядные индексы (000–111, так как имеются 8 значений), которые будут сохранены в блоках красным цветом через красный p во время сжатия.

Преобразование формата с помощью Direct3D 10.1

Direct3D 10.1 позволяет копировать между предварительно типизированными текстурами и текстурами, сжатыми блоком, одинаковыми битами ширины. Функции, которые могут выполнить это, — CopyResource и CopySubresourceRegion.

Начиная с Direct3D 10.1, можно использовать CopyResource и CopySubresourceRegion для копирования между несколькими типами форматов. Этот тип операции копирования выполняет преобразование формата, которое повторно интерпретирует данные ресурсов в качестве другого типа формата. Рассмотрим этот пример, показывающий разницу между переинтерпретированием данных с тем, как работает более типичный тип преобразования:

    FLOAT32 f = 1.0f;
    UINT32 u;

Чтобы переинтерпретировать "f" в качестве типа u, используйте memcpy:

    memcpy( &u, &f, sizeof( f ) ); // ‘u’ becomes equal to 0x3F800000.

В предыдущем переосмысление базовые значения данных не изменяются; memcpy повторно интерпретирует плавающее значение в виде целого числа без знака.

Чтобы выполнить более типичный тип преобразования, используйте назначение:

    u = f; // ‘u’ becomes 1.

В предыдущем преобразовании базовое значение данных изменяется.

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

См. также

Ресурсы (Direct3D 10)