nabbla (nabbla1) wrote,
nabbla
nabbla1

Categories:

QuatCore+GPU, строка 10 (дубль 2)

Быстренько проверим, что "ничего не поломали".

Теперь начало 10-й строки стало ровно таким же, как и до наших улучшений: ожидаем отправки двух заданий, первое отправляется строго по началу информативной части строки, второе - после обработки первого отрезка, от 0 до 0x0B:



А дальше будем просто искать DestAddr=0x20 - это команда ACQ, отправка очередного задания в видеопроцессор. Вот первый раз на 10-й строке тестового изображения, когда она появляется:


Ровно те же значения, 2 и затем 8, которые мы отправили в прошлый раз. Но в этот раз мы отправили их аж на один такт раньше. Это нам помогла замена Acc на ZAcc, но помогла не сильно, поскольку "параллельно" всё равно шла выборка из памяти. Всё по плану :)

И ещё на этом скриншоте видно возвращение из процедуры AcqQueue сразу же на метку @@MidCycle:

20  F363                          [SP++]  @@MidCycle      ;после вызова AcqQueue возвращаемся
21  89B8                          NOP     CALL(AcqQueue)  ;сразу на метку @@MidCycle
22  E0FC          @@DoMerge:      [Z+1]   [SP]    ;пока так           
23  DDCD          @@MidCycle:     Y       X
24  CDC8                          X       [X+k]                               
25  8879                          ZAcc    RoundZero


Как видно, по возвращении у нас PC=0x23 - ровно туда, куда и хотели!

Крутим дальше в поисках DestAddr=0x20 (ACQ). Находим вот что:


Как будто бы мы так и не удалили старую точку, и снова отдельно рассматриваем отрезок "под ней". Откручиваем назад:


И обнаруживается (хотя до этого можно было додуматься раньше), что когда мы поменяли поменяли местами уменьшаемое и вычитаемое, а потом заменили JL на JGE, это не была ЭКВИВАЛЕНТНАЯ ЗАМЕНА! Ведь и тогда, и сейчас мы получили НОЛЬ, и если в прошлый раз этого было достаточно, чтобы мы решили удалить точку, то теперь мы считаем "всё в порядке, пусть ещё один такт побудет".

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

Крутим дальше:


И снова знакомые все числа: 0x12 и 0x18, то есть и вторую точку мы не удалили, оно и ясно - их центры на одной строке расположены.

Но ещё мы замечаем, что счётчик в GPU досчитал до 0xEE, и следующим пошёл ноль - это началась следующая 11-я строка. Мы опять не успели! В первую очередь потому, что на отправке 0x12 мы опять застряли, тупо по причине нехватки места в буфере, поэтому мы и ждали начала полезной строки, когда уйдёт задание на синхроимпульс.

Так что сколько не ускоряй саму программу - в этом никакого смысла, пока не сделаешь входной буфер нормальной ширины! Иначе, даже на нормальной строке в 1024 пикселя, можно придумать вполне реальную ситуацию, где они все расположены в самом конце строки, и если мы не сможем сразу отправить все задания на обработку, то как раз и начнём ждать САМЫЙ ДЛИННЫЙ ОТРЕЗОК под 1000 пикселей, и только потом начнём шевелиться, когда станет уже поздно!

Чтобы эта картинка могла быть обработана "в реальном времени", входной буфер должен иметь длину 8. Тогда в нём может находиться одновременно синхроимпульс по "предыдущей" строке (в данный момент в работе), плюс 6 отрезков по новой строке и ещё и синхроимпульс для неё впридачу. Если так, мы сможем "застрять" уже непосредственно на приёме обработанного отрезка - этот момент мы уже никак не сможем ускорить!

А на выходной буфер должно хватить существующих 5 элементов, поскольку синхроимпульсы туда не попадают (они вообще сбрасывают выходной буфер), а самый первый отрезок на строке мы тут же "с пылу с жару" заберём себе.

Хорошо хоть, входной буфер не столь прожорлив, как выходной, и теперь вся схема в сборе занимает 1119 ЛЭ. Горшочек, не вари! Впрочем, мы сами сделали этот выбор - поставили FIFO на логических элементах, а не на памяти. Иначе, сожрали бы несколько блоков внутренней памяти, а количество ЛЭ снизилось бы где-то до 700.


Надо же, какая строка заколдованная - никак не можем её обработать нормально! Завтра должна "податься", и затем легко и непринуждённо - до самого низа, и моя надежда отладить это безобразие за 2 недели практически оправдается...
Tags: ПЛИС, программки, работа, странные девайсы
Subscribe

  • Нахождение двух самых отдалённых точек

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

  • Слишком общительный счётчик

    Вчера я чуть поторопился отсинтезировать проект,параметры не поменял: RomWidth = 8 вместо 7, RamWidth = 9 вместо 8, и ещё EnableByteAccess=1, чтобы…

  • Балансируем конвейер QuatCore

    В пятницу у нас всё замечательно сработало на симуляции, первые 16 миллисекунд полёт нормальный. А вот прошить весь проект на ПЛИС и попробовать "в…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments