5. СТАНДАРТНЫЕ ПИКСЕЛЬНЫЕ ФОРМАТЫ

Цель этой главы состоит в том, чтобы окончательно определить пиксельные форматы, тогда производители многочисленных компонентов могли бы разрабатывать их так, чтобы они функционировали на базе разнообразных аппаратных средств. Вследствие большого количества пиксельных форматов этой цели можно достичь лишь при условии, что в качестве общих стандартов будет выбрано небольшое (2-3) число этих форматов.

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

За информацией относительно метода конфигурирования устройств или апертур в специфические пиксельные форматы обращайтесь к соответствующим спецификациям программного обеспечения. Примерами таких спецификаций могут служить спецификация интерфейса управления дисплеем (Display Control Interface - DCI) и спецификация QuickTime.

5.1. Общие соглашения Соглашения по адресации

1.Адреса на шине PCI, связанные с пиксельными данными - это физические адреса байтов, а не логические адреса пикселей; то есть, адрес двойного слова (4 байта) в пакетном обращении на PCI подразумевает увеличение на единицу с каждой фазой данных (на два - при «широкой» передаче в 64 бита), независимо от того, являются ли пиксели 8, 16, 24 или 32-битными типами данных.

2.Разрешение байта показывает допустимость байтов в каждой фазе данных, как и в любой PCI-транзакции. Так как большинство форматов подразумевает множество байтов на пиксель, то не все комбинации разрешения байта могут иметь значение. Допустимые комбинации в этом случае определяются для каждого формата.

3.Сначала адресация пикселей осуществляется слева направо, а затем - сверху вниз. То есть, пиксель (n + 1) расположен справа от пикселя (n) (либо под ним, на следующей строке).

Перестановки

PCI может использоваться как шина расширения для <<little-endian>> и «big-endian» - процессоров. Для введения в силу инвариантной адресации, как требует спецификация PCI, необходимо наличие моста «хост - PCI». При соблюдении данного условия передаваемые через мост пиксели будут появляться с «переставленными байтами».

Представьте себе, например, большой процессор с граничными перестановками, который бы записывал пиксели в формате RGB-15+а в буфер кадров на PCI. Пиксели поступают на главную шину в

следующем виде:

Числа под байтами указывают на большие интервалы между байтами. Обратите внимание, что формат данных каждого пикселя такой же, какой и у приведенного ниже формата RGB-15+а; то есть, 1 бит для «альфы» и три 5- битовых поля для R, G, B.

Если посмотреть на мост со стороны PCI, то пиксели появляются в таком виде:

Числа под байтами указывают на порядок («little-endian») их следования на шине PCI. Обратите внимание, что расположение пикселей правильное, это является следствием инвариантной адресации моста.

Однако, в данных для каждого пикселя была применена перестановка байтов, и это также является следствием инвариантной адресации.

На следующей диаграмме, помеченной как «gib-endian», пиксели представлены в том виде, в котором они наблюдаются на PCI при передаче через хост «big-endian» к мосту PCI. На выходах, где «границы» явно не определены, может подразумеваться, что форматы «gib-endian» и «little-endian» эквивалентны. Поддержка форматов «Gib-endian» возлагается на производителя, однако, она требуется всем устройствам, которые являются целевыми для большого сегмента рынка «big-endian» - систем.

Альфа - поля

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

5.2. Требуемые пиксельные форматы

Очень важно понимать, что понятие «требуемые форматы» применяется только к тому формату, в котором пиксели передаются через шину PCI. Формат для хранения пикселей (например, в буфере кадров) - это прерогатива разработчика изделия. Когда формат отображения отличается от формата передачи, изготовитель свободен в выборе места, где будет выполняться преобразование. Например, для контроллера с буфером кадров преобразование можно выполнить на интерфейсе шины PCI, и таким образом пиксели будут сохранены в преобразованном формате, либо сохранение можно осуществить в формате передачи, с выполнением преобразования в ЦАП.

Когда формат хранения отличается от формата передачи, и устройство либо апертура предназначены для чтения / записи, то преобразование или передача должны быть двунаправленными, хотя могут и терять данные (см. раздел 3.2.1 для обсуждения апертур). Многие из таких преобразований очень просты. Например, преобразование из формата RGB-24 в формат RGB-15+а просто ведет к «вырезанию» младших битов при записи, и их добавлению - при чтении.

Требуемые пиксельные форматы определены в двух категориях:

Начальный уровень - требуется только формат RGB-15+а (как определяется ниже). Это наименьший формат, который может эффективно применяться для видео, и который сегодня доступен в большинстве графических PCI - контроллеров.

Уровень полного взаимодействия - требуются (в дополнение к RGB-15+а) форматы RGB-24+а и YUV-4:2:2 (оба приводятся ниже). Оба данных формата обеспечивают максимальное количество цветов для графики и видео, соответственно, таким образом, учитываются стандарты; в то же самое время они могут быть легко преобразованы (путем усечения) в более низкие разрешения для более дешевых буферов кадров.

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