[arexol 0]

Работаю на ADSP BF537 EZ -KIT 1,3

 

Занимаюсь проблемой вывода видео изображения

 

На данном этапе отладил механизм установки видео режимов - всё работает, так-же переключаются видеостраницы.

 

т.е на тестовом примере идет анимация заранее подготовленных кадров из SDRAM

 

Используеться только один банк сдрам-а

 

Был на семинаре в Киеве по блекфинам - там прозвучала фраза о том что максимальная разрешающая способность видео на блекфине определяеться максимальной пропускной способностью PPI порта , которая в свою очередь зависит от SCLK и равна SCLK/2 что в общем то вполне соответствует даташиту.

Т.е имем к примеру SCLK=120 Mhz и получаем что с частотой 60 MHZ можно выдавать данные из порта.

т.е при разрядности 16 бит имеем 120 Мегабайт в сек. что в общемто не превышает скорость чтения из сдрам в бурст режиме (по крайней мене я так понимаю)

 

У меня в примере процессор работает на частоте ядра 600 мгц и 120 мгц сдрам

 

Параметры видео таймингов следующие

 

1. это 640х480 60 Hz - всё работает отлично

 

PPI CLK period is = 0.040000 us (25 MHZ )

HOR_ADDR = 640 pixels

HOR_BLANK = 160 pixels

HOR_TOTAL = 800 pixels

VER_ADDR = 480 pixels

VER_BLANK = 21 pixels

VER_TOTAL = 525 pixels

TMR0_P (H) = 800 pixels

TMR0_W (H) = 160 pixels

TMR1_P (V) = 420000 pixels

TMR1_W (V) = 16800 pixels

timer0_width * CLKPPI_period = 6.400000 us

timer0_period * CLKPPI_period = 32.000000 us

timer1_width * CLKPPI_period = 672.000000 us

timer1_period * CLKPPI_period = 16800.000000 us

 

 

2. 1024х768 50 Hz - видеорежим устанавливаеться без проблем

но данные явно видно не успевают картинка срываеться

PPI CLK period is = 0.018018 us (55.5 Mhz )

HOR_ADDR = 1024 pixels

HOR_BLANK = 336 pixels

HOR_TOTAL = 1360 pixels

VER_ADDR = 768 pixels

VER_BLANK = 26 pixels

VER_TOTAL = 820 pixels

TMR0_P (H) = 1360 pixels

TMR0_W (H) = 336 pixels

TMR1_P (V) = 1115200 pixels

TMR1_W (V) = 35360 pixels

timer0_width * CLKPPI_period = 6.054054 us

timer0_period * CLKPPI_period = 24.504503 us

timer1_width * CLKPPI_period = 637.117050 us

timer1_period * CLKPPI_period = 20093.691250 us

 

 

Может ктонибудь сможет разьяснить что тут к чему ?

Взможно видеорежим всё-таки зависит не от максимальной пропускной способности PPI ?

если что не понятно могу более детализировать ситуацию - может параметры не верные?

за ранее благодарен за любую помощь.

[serg`o 0]

Ты напомнил мне случай когда индусский программист из АД жаловался что наша либа глючит при установки слишком больших входных буферов. В результате оказалось что так как передача данных происходит по ДМА то выходные буфера попросту не успевают заполняться... Т.Е. замерь время необходимое на обработку данных. С учетом того что данные ты читаешь из ВНЕШНЕЙ памяти, ктоторая значительно медленнее L1. Я думаю что для теста они помещали картинку внутреннюю память и лили ее по дма через порт. Тогда действительно все определяется только пропускной способностью канала. Но все таки замерь затраты на обработку. И может попытайся сделать двойную буферезацию для ускорения обмена данными как с внешним источником так и с внешней памяти.

[arexol 0]

Ты напомнил мне случай когда индусский программист из АД жаловался что наша либа глючит при установки слишком больших входных буферов. В результате оказалось что так как передача данных происходит по ДМА то выходные буфера попросту не успевают заполняться... Т.Е. замерь время необходимое на обработку данных. С учетом того что данные ты читаешь из ВНЕШНЕЙ памяти, ктоторая значительно медленнее L1. Я думаю что для теста они помещали картинку внутреннюю память и лили ее по дма через порт. Тогда действительно все определяется только пропускной способностью канала. Но все таки замерь затраты на обработку. И может попытайся сделать двойную буферезацию для ускорения обмена данными как с внешним источником так и с внешней памяти.

 

Так я ничего вообще не обрабатываю

в тестовом примере проц занимаеться только вызовом прерываний и назначение нового адреса для ДМА и все

в сдраме ничего кроме видеостраниц нет (вся програмная память и переменные во внутренней памяти)

 

На счёт того что буфера не успевают заполняться - не совсем понятно.

в СДРАМ есть режим FULL PAGE BURST когда идёт выкачивание всего банка сдрам-а.

в таком режиме у меня пропускная способность сдрама при чтении должна быть почти 240 МБайт/сек т.е в каждом такте по слову на частоте 120 мгц.

неужели не хватит ?

или БФ с бурст режимами не дружит ?

[Alex255 0]

Ты напомнил мне случай когда индусский программист из АД жаловался что наша либа глючит при установки слишком больших входных буферов. В результате оказалось что так как передача данных происходит по ДМА то выходные буфера попросту не успевают заполняться... Т.Е. замерь время необходимое на обработку данных. С учетом того что данные ты читаешь из ВНЕШНЕЙ памяти, ктоторая значительно медленнее L1. Я думаю что для теста они помещали картинку внутреннюю память и лили ее по дма через порт. Тогда действительно все определяется только пропускной способностью канала. Но все таки замерь затраты на обработку. И может попытайся сделать двойную буферезацию для ускорения обмена данными как с внешним источником так и с внешней памяти.

 

Так я ничего вообще не обрабатываю

в тестовом примере проц занимаеться только вызовом прерываний и назначение нового адреса для ДМА и все

в сдраме ничего кроме видеостраниц нет (вся програмная память и переменные во внутренней памяти)

 

На счёт того что буфера не успевают заполняться - не совсем понятно.

в СДРАМ есть режим FULL PAGE BURST когда идёт выкачивание всего банка сдрам-а.

в таком режиме у меня пропускная способность сдрама при чтении должна быть почти 240 МБайт/сек т.е в каждом такте по слову на частоте 120 мгц.

неужели не хватит ?

или БФ с бурст режимами не дружит ?

Ежели у вас сначала буфер заливается из внешней памяти со скоростью 240М/c, а потом (3 байта за цикл) со скоростью 180 М/с на дисплей, то сквозная скорость получается около 100 М/с. А для режима 1024х768 50 Hz 24бит нужно поболе малость...

[dryadae 0]

в СДРАМ есть режим FULL PAGE BURST когда идёт выкачивание всего банка сдрам-а.

В SDRAM'е он есть, но у Блэкфина его нет :(

 

Since the SDRAM burst length is always hardwired to be 1, the

SDC does not support the Burst Stop command.

 

Since the SDRAM burst length is always programmed to be 1, the

burst type does not matter. However, the SDC always sets the

burst type to sequential-accesses-only during the SDRAM powerup

sequence.

(ADSP-BF533 Hardware Reference Manual, rev. 3.2, стр 17-24)

[arexol 0]

Ты напомнил мне случай когда индусский программист из АД жаловался что наша либа глючит при установки слишком больших входных буферов. В результате оказалось что так как передача данных происходит по ДМА то выходные буфера попросту не успевают заполняться... Т.Е. замерь время необходимое на обработку данных. С учетом того что данные ты читаешь из ВНЕШНЕЙ памяти, ктоторая значительно медленнее L1. Я думаю что для теста они помещали картинку внутреннюю память и лили ее по дма через порт. Тогда действительно все определяется только пропускной способностью канала. Но все таки замерь затраты на обработку. И может попытайся сделать двойную буферезацию для ускорения обмена данными как с внешним источником так и с внешней памяти.

 

Так я ничего вообще не обрабатываю

в тестовом примере проц занимаеться только вызовом прерываний и назначение нового адреса для ДМА и все

в сдраме ничего кроме видеостраниц нет (вся програмная память и переменные во внутренней памяти)

 

На счёт того что буфера не успевают заполняться - не совсем понятно.

в СДРАМ есть режим FULL PAGE BURST когда идёт выкачивание всего банка сдрам-а.

в таком режиме у меня пропускная способность сдрама при чтении должна быть почти 240 МБайт/сек т.е в каждом такте по слову на частоте 120 мгц.

неужели не хватит ?

или БФ с бурст режимами не дружит ?

Ежели у вас сначала буфер заливается из внешней памяти со скоростью 240М/c, а потом (3 байта за цикл) со скоростью 180 М/с на дисплей, то сквозная скорость получается около 100 М/с. А для режима 1024х768 50 Hz 24бит нужно поболе малость...

 

 

Таким образом можно сделать печальный вывод

 

(Я обычно оцениваю грубо если допустим сдрам работает на 100 Мгц то максимальный допустимый трафик в рандом режиме составляет примерно 1/3 т.е 33 Мега слов в сек)

 

Значит поток данных максимум возможен 80 Мегабайт в секунду (частота 120 Мгц ) на все про все

а если вычитаем трафик для видео то совсем ничего то и не останеться. Особо не разгуляешься :(

 

Или может у кого есть другие данные по максимальному реально возможному(а не теоретическому) трафику по сдрам в блекфине ?

[Stanislav 0]

Или может у кого есть другие данные по максимальному реально возможному(а не теоретическому) трафику по сдрам в блекфине ?

Данные непосредственным образом следуют из даташитов на сдрам и процессор.

Если не хватает трафика - возьмите 561-й, у него шина данных толще.

[yes 5]

в СДРАМ есть режим FULL PAGE BURST когда идёт выкачивание всего банка сдрам-а.

В SDRAM'е он есть, но у Блэкфина его нет :(

 

 

ну а оно и не надо -

так как SDRAM пайплайновая штука, то затраты на смену адреса внутри страницы (если банк не закрывается, что верно для BF, и страница не меняется - что верно для последовательного доступа) равны 0

 

то есть если бы и был FULL PAGE BURST, то страница была бы считана ровно за то же самое время

[v_mirgorodsky 0]

в СДРАМ есть режим FULL PAGE BURST когда идёт выкачивание всего банка сдрам-а.

В SDRAM'е он есть, но у Блэкфина его нет :(

 

 

ну а оно и не надо -

так как SDRAM пайплайновая штука, то затраты на смену адреса внутри страницы (если банк не закрывается, что верно для BF, и страница не меняется - что верно для последовательного доступа) равны 0

 

то есть если бы и был FULL PAGE BURST, то страница была бы считана ровно за то же самое время

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

 

Даже 85% пропускной способности подсистемы памяти должно за глаза хватить для RGB 1024x768x50, поскольку суммарный поток составляет всего 56,25MB/s. PPI порта также должно хватать, поскольку есть еще ~6.5% запаса по пропускной способности. Однако в Киеве также упоминали о не 100% эффективности внутренней периферийной шины. Похоже, затык происходит именно в ней. Потому двойная буфферизация здесь возможно не поможет. Как вариант, можно попытаться данные хранить в памяти в 4:2:2 YUV формате и интерполировать их непосредственно перед выводом в PPI порт. Я подозреваю, что современные видеокарты используют 4:2:2 YUV по похожим причинам.

[dxp 34]

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

Может я чего-то не понял, но присоединяюсь к предыдущему оратору - длина burst, равная 1, не приводит ни к каким потерям в производительности - в пределах открытой "строки" (page) доступ произвольный на максимальной скорости. Единственное отличие от, скажем, burst = full page, это то, что при burst = 1 нужно на каждом обращении метать адрес элемента в "строке", а при full page этого делать не надо, он сам внутри SDRAM'ины инкрементится. Зато при burst = 1 выше гибкость - можно и в пределах "строки" иметь произвольный доступ, и порядок чтения памяти легко иметь реверсный.