Дурацкий вопрос по ПСП.

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

Входные данные:
- разрешение 1024x768 точек

- глубина цвета - 32бит (т.е. 4 байта на пиксел)
- частота обновления моника - стандартные 85Гц.

В качестве подопытного кролика возьмем какую-нить старую вижеокарту типо S3 Virge или Matrox Mystique/Millenium с объемом памяти ~4MB и интерфейсом PCI vulgaris (32bit x 33Mhz).

Считаем:
1024x768 x 4 bytes x 85Hz= 768KB x 340Hz ~ 256MB/sec... А у PCI ПСП - 133MB/sec max. Реальная - где-то в районе 80-90MB/sec. А теперь вопрос - как так получается, что отображение изображения на мониторе не вызывает ужасных тормозов оставшейся части системы?
Пока из предположений:
а) частота обновления монитора ничего общего с частотой поступления данных в видеокарточку не имеет.
б) вполне возможно сжатие данных по дороге от памяти к видеокарте. Хотя любое сжатие медлеееееенное.
в) данные надо передавать только при изменении картинки на экране. Причем достаточно передавать только тот кусок экрана, который изменится.

Допущения:
на самом деле это всего лишь грубая модель и очень грубые прикидки, но кажется проблема все-таки существует...
рассматриваем случай 2D. В 3D все веселее :) причем намного.

Так в чем же тогда хитрость?

Если данная информация оказалась полезной/интересной - плюсаните, пожалуйста:

Аватар пользователя GetinakS

1) 85гц на требуемую псп влияют только в цепочке videoprocessor-ramdac-monitor
2) На видеокарту действительно передается только измененная часть изображения
3) (ИМХО абсолютное, причем я и не уверен) именно это и объясняет, почему 1600х1200 в VESA режиме дает такие офигенные тормоза.

Broadcast message from PAO EC
Power is going down for shutdown NOW!

Аватар пользователя Baza

По моему, никто в видяху видеопоток не кидает. Там идут только инструкции что и как отрисовать

Либо нечему гореть, либо нечем поджечь!

Аватар пользователя Root

Baza
По логике происходит вообще следующее:
а) вся картинка десктопа хранится в памяти видеокарты
б) это все дело маппится на RAM


в) при изменении данных по этим адресам, они же гонятся напрямую в видеопамять. Т.е. по PCI перекачиваются только изменения.
Цитата:
Там идут только инструкции что и как отрисовать

это в 3D - полигоны, точки, цвета, текстуры и пр. пр. Хотя все равно все это дело можно упростить. Взять первые 3D-акселлераторы :)
GetinakS
Цитата:
именно это и объясняет, почему 1600х1200 в VESA режиме дает такие офигенные тормоза.

поподробнее плиз.
Цитата:
85гц на требуемую псп влияют только в цепочке videoprocessor-ramdac-monitor

и что за мегакрутая шина там получается? все равно как-то жирновато :)

Аццкий ромбовод {:€
Я пока не волшебник - я только учусь! :-P

Предлагаю разделить 2Д и 3Д, ибо вторым сам хотел заняться


А в первом передаются только изменения экрана, сам он хранится в видеопамяти (помним ещё ограничения на разрешения и цвет на S3Trio?). А передача RAMDAC->VGA идёт и вовсе по высокой частоте, сходной с частотой рамдака (сотня-другая мегагерц). Ибо вы не забыли, что помимо вертикальной частоты есть ещё горизонтальная? Там вообще в районе 98КГц (Килогерц!) выходит горизонтальная. Ибо мы пробегаем строки, а потом ко столбцам переходим.

А раз передаём изменение, то и ПС слота не даст ничего в 2D. Хотя из вариантов -запустить тест fill rate, может сказаться. В 3D же ситуация интереснее.

Вместе мы - www.ROM.by!

Root писал(-а):
GetinakS
Цитата:
именно это и объясняет, почему 1600х1200 в VESA режиме дает такие офигенные тормоза.

поподробнее плиз.

Root, поставь 1-2 метровую PCI карточку, влупи максимальный режим, сделай, например, скроллинг окна с плавным эффектом и сам все увидишь...:D

Root писал(-а):
б) это все дело маппится на RAM

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

Alles Luge...

Аватар пользователя savely

Итак
Связка N1 - память + RAMDAC. Отвечают за герцы, битность, разрешение. RAMDAC может быть встроенным или внешним.
Связка N2 - видеопроц + память. Видеопроц получает RAW-данные для записи в память или граф.примитивы (типа нарисуй линию) или в 3D - какие-то инструкции. Не забываем, что 2D-ускорению больше лет, чем 3D.
Память - двухпортовая или мультиплексируемая между видеопроцом и RAMDAC.

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

Маппинг "нижней" (до мега) памяти работает только в текстовых и маленьких графических режимах. Соотв. - текст с B800, графика - с A000:0 до C000:0 (EGA-режимы, что-то из VGA - лень искать). Верхней (от гига до 4-х) - согласно PnP. Маппится не на RAM, а на адресное пространство. Т.е. RAM видеокарты торчит на PCI. Кстати, не факт, что у S3 так - в те времена мог торчать и порт с автоинкрементом адреса. Т.е. туда "rep outsd"'ом загонялось. Хотя у Матрокса G200 (то, что из старых в работе) - торчит память.

Таким образом - в 2D шину никто особо не жрет. Гнать по шине 85 раз в секунду всю картинку не надо - вывести ее 85 раз в секунду c нужным (возможным) разрешением - задача связки N1 (т.е. RAMDAC и видеопамять должны успевать, видеопамять быть достаточного объема). И только при полной смене 2D-картинки мы получаем моментальный поток во всего лишь 1024x768 x 4 bytes = 3MB/sec... При 1600x1200x32 - 7,3 МB/sec, что занимает 1/10 sec и мы наблюдаем видимые тормоза.

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

А кому счас легко...

Аватар пользователя Root

savely
угу-мс - насчет RAMDAC'а и видеопроцессора это все на самом деле очевидно :)
Но вот с арифметикой у тебя все равно проблему. А у меня с русским :) как видите

Цитата:
И только при полной смене 2D-картинки мы получаем моментальный поток во всего лишь 1024x768 x 4 bytes = 3MB/sec...

а за какое время? 1024x768 px x 4 bytes per piksel = 3MB... А за какое время эти 3МБ перегонятся - еще вопрос. Так что как раз и получается, что мы можем "моментальный поток" получить зашкаливающий за возможности PCI.

Аццкий ромбовод {:€
Я пока не волшебник - я только учусь! :-P

По 2D:
Разрешение - N x M пикселей
Глубина цвета - k бит/пиксель
Частота обновления изображения - F кадров/с
Доступная ПСП PCI - P Мбайт/с
Предположим, что изображение обновляется полностью и процессор может обеспечить любой поток данных без задержек.
Интересует результирующая частота обновления изображения при заданных остальных параметрах.
F=(2^23)*P/(N*M*k)
Примеры:
При P=80 Мбайт/с, N=1024, M=768, k=32, F=26,7 кадров/с
При P=80 Мбайт/с, N=1600, M=1200, k=32, F=10,9 кадров/с
Соответственно, можно оценить комфортность работы при заданных параметрах изображения (идеализированный случай, который не полностью описывает реальную работу шины PCI и прочих устройств;)).

Аватар пользователя Baza

Немного не в тему, но про войну:

я тут озаботился возможностью комфортного просмотра HDTV (1920х1080) h.264 на Туалатинах:)

так похоже я упёрся в ПСП, только не шины видеокарты, а процессора:(



т.к. даже при видеокарте с поддержкой аппаратного декодирования h.264 (GF7600GS)  имею подтормаживания и рассыпание картинки...при том что загрузка обоих камней далека от 100%, что при софтовом, что при аппаратном декодировании:(



гонялось всё на 2x PIII-S 1133 (1260) +MS-9105 +2048 DDR PC3200

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

картинка наилучшего качества по скорости была почему-то при самом тяжёлом случае кодирования исходного файла

и при самой большой загрузке ЦПУ (80-100%)



так что думаю, что даже погнанная до 150МГц шина данных П3 не спасает.....а жаль.


Либо нечему гореть, либо нечем поджечь!

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Разрешённые HTML-теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img>
  • You can use BBCode tags in the text. URLs will automatically be converted to links.

Подробнее о форматировании текста

Антибот - введите цифру.
Ленты новостей