Перейти к содержанию
    

Непонятки с портированием ассемблерной функции из ГЦЦ в ИАР

30.07.2020 в 13:25, mantech сказал:

Если это так, то как можно его сбросить?

Вообщем, кому интересно, ничего сбрасывать не надо, проблема была в этой строчке:

for (i = 0; i < 16; i++) *src++=c; //заполняем константой цвета 64 байта

Непонятно почему, но она не работала как нужно. Если в место 16 стоит 8 - работает, если кому не сложно, объясните почему, вроде тут все очевидно...

Тестировал на IMX6S-800МГц. Так вот какие получились результаты:

Рисование заполненного прямоугольника (1366х768 32бита цвет):  35мсек, 110мсек, 8мсек

Копирование экрана этого же разрешения их буфера в экр. область: 210мсек, 110мсек, 35мсек

Первое число - программно(memcpy/memset), 2е число- SDMA,  3е- NEON

Как видно SDMA имеет преимущество только при копировании, заполнение идет гораздо медленнее, чем программно(это в том случае, если экр. область отмечена как буфер в настройках ММУ, в противном случае, программное заполнение будет медленнее SDMA), преимущество NEON во всех случаях, что странно, даже чуть-чуть быстрее, чем IPU...

Но самое главное его преимущество, что этот модуль есть во всех кортексах А-серии, и нет нужды что-то переделывать при переходе на камень другого производителя, копаться в его плоходокументированных контроллерах дисплея и т.п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 minutes ago, mantech said:

преимущество NEON во всех случаях, что странно, даже чуть-чуть быстрее, чем IPU...

Но самое главное его преимущество, что этот модуль есть во всех кортексах А-серии, и нет нужды что-то переделывать при переходе на камень другого производителя, копаться в его плоходокументированных контроллерах дисплея и т.п.

 

Слава великому NEON-у!!! :i-m_so_happy:

 

P.S. Ещё бы с кешами провели эксперимет как я писал ранее (бит TEX)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

10 минут назад, __inline__ сказал:

Ещё бы с кешами провели эксперимет как я писал ранее (бит TEX)

Мудрено разбираться, в МХе, настройки ММУ выдраны из их сдк, там черт ногу сломит, помню, еле -еле разобрался и забыл)))

Если будет дофига свободного времени можно проверить... Да и ядро там А9, оно на сколь помню, от А7 отличается...

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/27/2020 at 8:55 PM, mantech said:

Функция написана под ГЦЦ.

Простите, возможно я чего-то не понимаю, но вы копируете данные с помощью FPU? Если это так, то не могли бы вы рассказать, почему и  в каких случаях выгодно использовать сопроцессор для копирования? На официальном сайте arm подобной информации найти не могу. А упоминание ускорения операций копирования сопроцессором встречал неоднократно на этом форуме. Заранее спасибо)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 часов назад, haker_fox сказал:

но вы копируете данные с помощью FPU?

Это не FPU, это потоковый сопроцессор, который может выполнять несколько однотипных операций в 1й команде. Например, чтоб записать данные в память, процессор запишет только 4 байта за команду, здесь можно писать сразу по 64 байта. В случае статической памяти на частоте проца это особо не ускоряет запись, но в данном случае контроллер памяти может работать сразу блоком(burst-режим), что гораздо быстрее, чем произвольный доступ по команде процессора. Чтение так же точно, "выгоднее" читать сразу блоком, чем по 4 байта за операцию. Но есть и минус - пакет в 64 байта означает, что с таким шагом и придется работать, в моем случае по 16 пикселей, если требуется некратное этому значение, придется дополнять программно, но это не существенно влияет на общюю скорость, т.к. неоном выполняется 95-99% работы.

 

ЗЫ. Еще несколько моментов, неон может работать с 1, 2, 4 или 8 регистрами, но заметил такую вещь, если работать с 4я, т.е. по 32 байта, то начальный дрес должен быть кратным 2м,  иначе скорость резко падает (до 2х раз), если работать по 64 байта, то кратность начального адреса не важна. При использовании 1го регистра скорость такая-же, как у процессора, 2х немного выше, но более заметно на копировании.

 

Регион памяти получателя должен быть как минимум настроен в буферный режим, иначе скорость резко упадет, источник использовал некешируемый регион, кеширование ускоряет на 40% чтение, но есть проблемы с кэшем, поэтому решил не использовать.

5 часов назад, haker_fox сказал:

На официальном сайте arm подобной информации найти не могу.

Да она там есть, но разбираться с ней - это целая история...

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, mantech said:

Да она там есть, но разбираться с ней - это целая история...

Если есть ссылочки прямые, не поделитесь?) А за объяснение про сопроцессор - спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 часа назад, haker_fox сказал:

Если есть ссылочки прямые, не поделитесь?)

Без проблем - https://developer.arm.com/documentation/100076/0100/

по ней скачаете пдфку, на 449стр описание VLDM и т.п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...