При адресации источника, блок отображения должен размещаться в приемнике видеоданных, то есть, в дисплее или подсистеме памяти. Часть функции масштабирования можно перенести обратно в источник, но в противном случае довольно трудно было бы как-то иначе разместить функцию для работы с окнами.

Когда функции формирования окон реализованы в источнике видеоданных, необходимо их правильное и четкое распределение: каждая определенная функция необходима для какого-то определенного источника видеоданных. Тем не менее, обеспечение правильного числа блоков формирования окон в приемнике видеоданных может привести к появлению трудностей при проектировании. Графические контроллеры и подсистемы памяти не имеют какого-то встроенного ограничения по числу окон, которые могли бы быть активны одновременно, но подключение аппаратных средств для работы с окнами искусственно создает такие ограничения. Слишком большое количество блоков для работы с окнами порождает проблему стоимости, в то время как их слишком малое количество ведет к неизменным аппаратным ограничениям.

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

Данные ограничения, вносимые моделью адресации источника, являются причинами для рекомендации использования адресации приемника.

Вмешательство

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

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

Другие решения

Имеется еще несколько проблем, связанных с адресацией источника или «широковещательными» транзакциями.

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

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

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

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

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

В качестве простого примера использования апертур может являться поддержка процессора (который бы обрабатывал графические данные) и источника видеоданных (который предоставляет исходные цифровые видеоданные), использующих один и тот же буфер кадров. Если форматы пикселя для этих двух источников не идентичны, то возникает проблема. Например, если процессор обращается к пикселям в формате 1-5-5-5 RGB, а источник видеоданных поставляет данные в формате 2-1-1 YUV, то как можно в этом случае предоставить одновременный доступ?

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

гарантировать, что из источника не поступало видеоданных, когда процессор обращался к буферу кадров (frame buffer), и наоборот. Это, возможно, значительно усложнило бы мультимедийную систему.

3.2.1. Апертуры

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

Следующие два конкретных примера иллюстрируют полезность механизма апертур.

3.2.2. Преобразование цветовых палитр

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