Ремонт принтеров, сканнеров, факсов и остальной офисной техники


назад Оглавление вперед




[6]

На рисунке 8 показаны две апертуры, одна - для процессора и вторая - для источника видеоданных; обе отображаются на общий физический буфер пикселей.

На этом рисунке размеры апертур (то есть число байтов внутри адресного пространства) отличаются, даже если число пикселей (например, 1024х768) одинаково. Это происходит потому, что число байтов, требуемых для представления, зависит от размера пикселя в байтах внутри данного представления.

В данном примере процессор и источник видеоданных могут обращаться к буферу кадров одновременно. Если мы принимаем, что буфер кадров физически сохраняет пиксели в формате RGB, который подразумевает процессор, то для доступа процессора к данным не требуется никакого преобразования. Однако, например, может потребоваться преобразование видеоданных источника из формата YUV в формат RGB. Контроллер буфера кадров «знает», какое должно осуществляться преобразование, отслеживая, в какой апертуре записываются пиксели.

Обратите внимание, что не все преобразования «простые». В этом примере источники видеоданных обращаются к буферу кадров «только по записи»; чтение пикселей в формате YUV привело бы к потере данных. Аналогично, чтение пикселей, которые физически сохранены в формате RGB с 24 битами, не может обеспечивать доступ по чтению с наименьшими потерями через апертуру 1-5-5-5; чтение же таких пикселей через апертуру CLUT с 8 битами не может быть возможным вообще.

Предположение, сделанное в этом примере, заключается в том, что каждая апертура представляет весь буфер кадров. Однако, высота и ширина для разных апертур или физического буфера могут отличаться. Таким образом, например, можно использовать апертуры для представления «подвидов» физического буфера.

3.2.3. Преобразование с перестановкой

В другом случае апертуры являются соответствующим механизмом, имеющим дело со смешанными «конечными» представлениями пикселей; например, в «big-endian» процессоре , который обращается к небольшому оконечному PCI - буферу кадров. Главный PCI - мост выполнил бы «перестановку байта» данных, чтобы гарантировать неизменность адреса, что требуется спецификацией PCI. Если гарантируется, что пиксели размещаются правильно (то есть, адрес и байт при этом корректные), то это может вызвать перестановку байтов пикселя.

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

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

Прим. перев.: «Endian» - это термш для описания порядка, а котором байты размещаются ia шине. Аёу шин типа Intel эти байты располагаются в убывающем порядке (little endian). Y6i означает, что байт 0 размещен в информационных разрядах 7-0, причем нулевой является самым младшим. Ааёб 1 - это биты с 15 по 8, ааёб 2 - с 23 по 16 ё ааёб 3 - c 31 по 24. Шина «big-endian» - это, например, шина типа Motorola. Здесь байт 0 - это биты с 31 по 24, ааёб 1 - биты с 23 по 16, ааёб 2 - биты с 15 по 8 ё байт 3 - биты с 7 по 0. А зависимости i6 того, какие используются микропроцессор ё шина ввода - вывода, вам может понадобиться переключать маршруты байта. Так как PCI - это шина «little-endian», то для применения частей с архитектурой Motorola потребуется некоторая дополнительная логика для «переключения» байтов. Обратите внимание, что для байтовой адресации и адресации данных типа байта данная проблема решается очень просто. Однако, для 16-ти и 32 - разрядных данных, или упакованных

пиксельных форматов это сделать намного труднее.


Рисунок 9: Преобразование с перестановкой

Взамен этого, контроллер буфера кадров мог бы реализовывать (по крайней мере) две апертуры. Одна апертура осуществляла бы «big - endiam-представление буфера кадров, в то время как другая - «small-endiam-представление. Заметьте, что базовое «big-endian»- преобразование - это всего лишь простая перестановка байтов, базирующаяся на размере пикселя (например, 16 бит). Таким образом, ее можно относительно просто реализовать в существующих разработках контроллеров, которые поддерживают множество пиксельных форматов, так как основные методы мультиплексирования данных уже существуют.

3.2.4. Реализация апертур

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

Так как механизм апертуры использует адрес «логических» пикселей, чтобы определить, к какой апертуре осуществляется специфический доступ (концептуально согласовывая базовые пары адрес/размер), адресные интервалы апертур должны быть различны, независимо от любого подобия между их остальными параметрами. Как только принимается какая-то апертура, атрибуты, связанные с этой апертурой (например, пиксельный формат, границы), определяют, какие необходимы преобразования для отображения между логическим и физическим представлением апертуры.

При простой реализации апертур можно было бы использовать старшие «совмещенные» биты буфера пикселей для того, чтобы определить, к каким апертурам относится доступ. Например, если буфер кадров реализует 2 апертуры, то для определения апертуры можно было бы просто использовать старший бит адреса, по которому осуществляется доступ4 .

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

4 Заметьте, что адресное пространство здесь не является проблемой. Даже такая сложная реализация, как 8 полных апертур в 16-Мб буфере кадров (2K x 2K x 32 бита), использует только 3% доступного 32-

битного адресного пространства.


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

3.2.5. Атрибуты апертур

Апертуры имеют соответствующие атрибуты, которые определяют действия контроллера, когда осуществляется доступ к конкретной апертуре. Среди этих атрибутов:

•Логический формат пикселя. То есть, цветовая палитра, представление, границы.

•Размер и организация логического буфера кадров. То есть, базовый адрес, ширина, высота, строки байтов, атрибуты чтения-записи.

•Физическое отображение. То есть, как логическое представление отображается в физическом буфере.

3.2.6. Конфигурация апертуры

Механизм апертуры предполагает, что драйвер устройства контроллеров поддерживает API - вызовы (Application Program Interface - интерфейс прикладных программ), которые позволяют обращаться к возможностям апертур контроллера и инициализировать апертуру от имени прикладной программы.

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

Число апертур, которое устанавливается атрибутами апертур и т.д., зависит от устройства и здесь не определяется. Модель драйвера устройства обеспечивает уровень абстракции, который «скрывает» эти подробности низкого уровня от прикладных программ, как это показано на рисунке 10.

Рисунок 10: Конфигурация апертуры



[стр.Начало] [стр.1] [стр.2] [стр.3] [стр.4] [стр.5] [стр.6] [стр.7] [стр.8] [стр.9] [стр.10] [стр.11] [стр.12] [стр.13] [стр.14]