5.Глубина FIFO от 4 до 8 (32 бит) является теперь общепринятой, а глубина FIFO более, чем 64 бит смотрится, вероятно, очень хорошо вне пределов точки «возвращения назад».

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

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

Предположения:

1.Поток 4 (видео для сжатия) - в формате YUV4:2:2. Он производится путем горизонтального масштабирования 640 * 240 четных полей к 320 * 240. В результате получается 640 байтов на строку.

2.Поток 5 (видео на FB) - в формате RGB16. Он производится путем горизонтального масштабирования 640 * 240 нечетных полей к 320 * 240. В результате также получается 640 байтов на строку.

3.Принята системная топология 3: модуль сбора видеоданных, модуль сжатия видеоданных и графика находятся на вторичной шине PCI.

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

5.Сжатие видео осуществляется по заднему фронту PCI, который введет 1 состояние ожидания до первой передачи данных и 0 состояний ожидания для всех остальных случаев, давая в общем случае 7 циклов, включая подтверждение шины.

6.Графический контроллер имеет те же характеристики, что и в пункте 5.

Обратите внимание, что в течение любой данной 1/60-ой секунды, активен только один из потоков 4 или 5. Таким образом, с точки зрения записи блоками, мы должны рассмотреть только один из этих потоков. Остальная часть обсуждения сосредоточится на потоке 5.

Наихудший случай ограничения пропускной способности имеет место, когда активна горизонтальная линия. Типичный декодер / блок масштабирования NTSC, эксплуатируемый в режиме, описанном здесь, будет производить 2 байта (данных в формате RGB16) каждые 160 нс (NTSC - пиксель производится каждый ~80 нс, уменьшение в 2 раза дает 160 нс).

Давайте выберем 2 нс - окно в середине активной линии. В это время декодер сгенерирует (2 мкс/160 нс)* 2байта = 25 байтов новых данных. Размещение этих данных потребует 25/4 (байтов / xfr) или ~7 фаз данных PCI.

Во время пиковой передачи, эта загрузка занимает 14 тактов из 66, доступных в цикле арбитража. Данный расчет подразумевает, что как только устройству сбора видеоданных предоставят шину, то оно будет использовать ее очень хорошо (пакетный режим и нулевые состояния ожидания). Следовательно, буфер FIFO должен обеспечить место для сохранения ~25 байтов в дополнение к другим 25 байтам, описанным выше (итого: ~50 байтов).

4.3. Проблемы производительности моста

Мост PCI-to-PCI между ЦП и графическим контроллером может влиять на производительность графики в трех случаях: при записи FB; при чтении FB и при опросе состояния. Так как время задержки чтения значительно не изменяется (без конфигурации моста), то операции чтения FB оказывают на производительность весьма незначительное воздействие, так как в большинстве случаев записи FB влияют на 95% 99%. Записи FB чувствительны к задержкам постольку, поскольку дополнительная задержка ведет к появлению состояний ожидания на выводах ЦП. Как только ЦП начнет работать дальше, последовательная задержка при записи перестанет быть проблемой. Следовательно, необходимо строго учесть данную проблему путем встраивания в мост буфера с регистрацией соответствующих операций записи.

Проблема опрашивания состояний немного более тонкая. Когда время опроса (а это операция чтения на шине) увеличивается, то становится необходимым (~10%) сравнивать его со временем выполнения небольших команд BitBLT или ускорителя. Это особенно верно для получения формы шрифта от кэша экранного шрифта, так как команды BitBLT имеют малое время выполнения. Даже со штрафом в 10 % за небольшие операции в BitBLT, общий штраф был бы << 10%, что не являлось бы серьезной проблемой. Тем не менее, есть несколько способов уменьшить при опросе эту дополнительную задержку, понесенную мостом PCI-to-PCI.

1.Односторонний сигнал: задержка опроса должно полностью избегать сигнала «команда завершена».

2.Очередь команд: очередь команд со множеством уровней в графическом контроллере может смягчить эффект задержки опроса, переводя графический контроллер в состояние ожидания процессора.

4.4. Другие проблемы

Полная производительность PCI - возможности вторичной шины

Введение вторичной шины PCI в систему предлагает некоторые выгоды, связанные с повышением производительности:

1.Мультимедиа - ориентированный арбитраж легко делает возможным «гарантированную доставку» потоков пикселей и других больших объемов данных в режиме реального времени.

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

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

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

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

Ограничения, свойственные только первичной шине - производительность / время ожидания

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

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