mantech 139 August 9, 2020 Posted August 9, 2020 · Report post 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... Но самое главное его преимущество, что этот модуль есть во всех кортексах А-серии, и нет нужды что-то переделывать при переходе на камень другого производителя, копаться в его плоходокументированных контроллерах дисплея и т.п. Quote Share this post Link to post Share on other sites More sharing options...
repstosw 22 August 9, 2020 Posted August 9, 2020 · Report post 8 minutes ago, mantech said: преимущество NEON во всех случаях, что странно, даже чуть-чуть быстрее, чем IPU... Но самое главное его преимущество, что этот модуль есть во всех кортексах А-серии, и нет нужды что-то переделывать при переходе на камень другого производителя, копаться в его плоходокументированных контроллерах дисплея и т.п. Слава великому NEON-у!!! P.S. Ещё бы с кешами провели эксперимет как я писал ранее (бит TEX) Quote Share this post Link to post Share on other sites More sharing options...
mantech 139 August 9, 2020 Posted August 9, 2020 (edited) · Report post 10 минут назад, __inline__ сказал: Ещё бы с кешами провели эксперимет как я писал ранее (бит TEX) Мудрено разбираться, в МХе, настройки ММУ выдраны из их сдк, там черт ногу сломит, помню, еле -еле разобрался и забыл))) Если будет дофига свободного времени можно проверить... Да и ядро там А9, оно на сколь помню, от А7 отличается... Edited August 9, 2020 by mantech Quote Share this post Link to post Share on other sites More sharing options...
haker_fox 162 August 10, 2020 Posted August 10, 2020 · Report post On 7/27/2020 at 8:55 PM, mantech said: Функция написана под ГЦЦ. Простите, возможно я чего-то не понимаю, но вы копируете данные с помощью FPU? Если это так, то не могли бы вы рассказать, почему и в каких случаях выгодно использовать сопроцессор для копирования? На официальном сайте arm подобной информации найти не могу. А упоминание ускорения операций копирования сопроцессором встречал неоднократно на этом форуме. Заранее спасибо) Quote Share this post Link to post Share on other sites More sharing options...
mantech 139 August 10, 2020 Posted August 10, 2020 (edited) · Report post 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 подобной информации найти не могу. Да она там есть, но разбираться с ней - это целая история... Edited August 10, 2020 by mantech Quote Share this post Link to post Share on other sites More sharing options...
haker_fox 162 August 10, 2020 Posted August 10, 2020 · Report post 1 hour ago, mantech said: Да она там есть, но разбираться с ней - это целая история... Если есть ссылочки прямые, не поделитесь?) А за объяснение про сопроцессор - спасибо! Quote Share this post Link to post Share on other sites More sharing options...
mantech 139 August 10, 2020 Posted August 10, 2020 · Report post 4 часа назад, haker_fox сказал: Если есть ссылочки прямые, не поделитесь?) Без проблем - https://developer.arm.com/documentation/100076/0100/ по ней скачаете пдфку, на 449стр описание VLDM и т.п. Quote Share this post Link to post Share on other sites More sharing options...
