Jump to content

    

__inline__

Участник
  • Content Count

    919
  • Joined

Everything posted by __inline__


  1. Это вы зря так! Есть одно золотое правило: "то, к чему прикасается бизнес - становится какашкой"... Поэтому, не стройте иллюзий, что дядечка, на которого пойдёте батрачить работать будет вам помогать в освоении. Скорее наоборот: вы вскоре возненавидите свою работу и увлечение. Поэтому даю 2 рекомендации: 1) работа - работой, а увлечение - увлечением 2) развивайтесь самостоятельно в своём увлечении - во всяком случае, сохраните интерес к делу и будете расти! Пусть и не будете профи на бумажке, зато будете довольны тем, что вы свободны в этой области и имеете свободу выбирать - познавать то, к чему душа лежит без ограничений по времени. ... а путь сделать хобби работой - тупиковый и ведёт к творческой импотенции.
  2. Не умеет. Тот загрузчик что самописанный, грузящий с SD-карты - сидит в этой самой L2. Если туда ещё быстрый код грузить, то загрузчик сам себя перетрёт
  3. я с ними наигрался.. могу отдать обе или одну.
  4. И куда подевался топик-стартер? Очень интересно, решил ли он задачу с синхронизацией вывода картинки и отображением на своём дисплее, или нет? Эти ощущения очень индивидуальны. У меня к примеру глаз очень придирчив, и я вижу артефакты, когда ристуют не по VSync'у. Другие не замечают или это явление им не мешает. Кроме тиринга (разрезания), есть ещё эффект подёргивания, который особо видно, если картинку смещать по горизонтали. Так что тут только вертикальная синхронизация.
  5. Это всё хорошо, покуда отладка. Когда приложения надо грузить из SD-карты, то в случае с C6745 встаёт вопрос изобретения велосипеда собственного загрузчика. У allwinner в этом плане гибче: не надо припаивать SPI-ПЗУ микросхему. Но загрузчик свой всёравно писать придётся (хотя и тут можно взять у-бут, но я захотел хардкора) И кстати, глянул свои программы, там кода(имеено - кода!) на сотни кБ, так что оптимальнее всего отдать внутреннюю память на L2 В кеше.
  6. Для мелких эмуляторов это делать смысла нет - они и так летают хорошо, что притормаживать приходится. А большие эмуляторы занимают несколько сотен килобайт кода. Но для нативных игр надо попробовать, предварительно глянув размер секции TEXT. В C6745 нет L3. Только L 1,2. Такой подход действительно более производителен. Но не сильно универсален, так как это потребует от загрузчика дифференцировать адреса по которым загружать секции. Сейчас у меня в упрощённом варианте - загрузчик валит весь бинарник в начало SDRAM.
  7. Ну скажем так, не на AVR'ку, а на вшивый нордик (Cortex-M с 64 МГц). А я так и не дождался "видимых результатов", когда запускал A13 и V3s без кешей (с внешней памяти). Возможно, просто не хватило терпения На C6745 кеш L2 (второго уровня) давал ощутимый прирост. Без него часть эмуляторов местами подтормаживала. При этом из 256K было выделено на кеш L2 всего 64К (остальная память была отдана экранному буферу). Кеши L1P, L1D включены естественно (их если что, тоже можно дробить - давать на кеш только часть памяти, остальные - на свои нужды).
  8. Нашёл свой пост, год назад писал об этом очень подробно с примерами как сделать:
  9. Там очень мощные требования: поворот, отражения, альфа, маскирование бит цветовых каналов, перестановка RGB, очёрно-беливание , и многое-многое другое.... :)
  10. Это не беда. TE можно считать через регистр (или номер рисуемой линии). У меня LCD с ILI9341 работал "на ура" и без кривляний картинки. И заливка двумя цветами блынькала без диагональных линий
  11. можете умножить на 4, так как 4 плоскости :) ну и DMA использую в основном для фен-шуя, на самом деле одного CPU хватает пока.
  12. Мне бы для игр пригодилось! Копировать отрендерённый задний буфер на экран целиком весь: позиции X, Y = 0, ширина 400 пикселей, высота 240. В ограничения укладываюсь! Объектики для игры рисую через CPU: спрайты всякие, иконки, меню.... - в задний буфер. Потом копирую его на экран DMA.
  13. Перепробовал все комбинации битов. Нашёл ещё одну, которая даёт тоже самое максимальное быстродействие(для DST -приемник): TEX=4, C=0, B=0. скорость аналогична с: TEX=1, C=0, B=1 В доках очень мутно расписано, и надо быть профессором кислых щей ARM'ов, чтобы вообще понять что происходит. Тем более комбинация при TEX=001 C=0 B=1 - зарезервирована, а по факту - одна из быстрых при копировании. Мало того, документ умалчивает об Outer policy и Inner policy... Мутно как-то всё. Дополнительно пытался использовать L2 кеш, но я разницы в скорости вообще не вижу - складывется впечатление, что либо L2 уже работает, либо он так и не включился. L2 включаю таким кодом: @ ================================================================== @ Enable Cortex-A8 Level2 Unified Cache @ ================================================================== MRC p15, 0, r0, c1, c0, 1 @ Read Auxiliary Control Register ORR r0, r0, #2 @ L2EN bit, enable L2 cache @ ORR r0, r0, #(0x1 << 4) @ Enables speculative accesses on AXI @ ORR r0, r0, #(0x1 << 5) @ Enables caching NEON data within the L1 data cache MCR p15, 0, r0, c1, c0, 1 @ Write Auxiliary Control Register При этом если раскомментировать: Enables speculative accesses on AXI и Enables caching NEON data within the L1 data cache, то на выходе не вижу разницы в быстродействии копирования NEON-ом. Зато обязательно надо установить бит 6 вот здесь (писал в соседней теме, сдублирую): /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */ asm volatile( "mrc p15, 0, r0, c1, c0, 1\n" "orr r0, r0, #1 << 6 \n" "mcr p15, 0, r0, c1, c0, 1\n" ); Иначе во внешней памяти программа будет крайне медленно работать, особенно когда будут читаться данные. Этот бит разрешает режим когерентности для CPU. Тут надо быть профессором кислых щей, чтобы разобраться как оно влияет на производительность.
  14. А для источника кеширование надо включать. Потому что у меня это задний буфер, и я из него читаю ещё... Если отключить кеширование в источнике, общая скорость проседает. И TEX для источника должен быть =0. Иначе мусор пойдёт. Объяснить не могу почему, так как не профессор в АРМ-ах :) Установил экспериментально
  15. :) я про то, что кеширование региона для приёмника наоборот надо ОТключить :) Ещё один плюс - делать clean/flush data cache при этом не нужно :)
  16. Я тоже из референса ничего там не понял ))) Вот, подтверждают, что регион должен быть с выключенным кешем(приемник) для NEON-memcpy: https://stackoverrun.com/ru/q/9617352 иначе с включенным битом кеша для региона приемника скорость просядет (писал об этом выше, замерял таймером с 6 МГц-разрешением)
  17. Ещё битовое поле TEX=1 в приемнике. Но об этом почему-то не пишут. Экспериментально обнаружил ускорение используя это поле. На ПК тоже были недокументированные вещи - типа MSR-регистров, включающие кеширование видеопамяти. В итоге CPU писал в 2,5 раза быстрее, чем при дефолтных настройках BIOS'а после загрузки :)
  18. А включенный бит буферизации? Он помогает конвееризировать бурсты? Ещё по теме быстрой отрисовки: https://stackoverflow.com/questions/11161237/fast-arm-neon-memcpy
  19. "VLDM %[src]!,{d0-d7} в область памяти с адреса src записывается содержимое 8-ми 8-байтовых регистров d0,d1,...,d7 за раз! Адреса должны быть выровнены на 64 байта и передача кратна 64-м. Для быстрой очистки экрана подходит
  20. Да, на A13 быстрее, чем у V3s! Да. Из-под цикла инструкцию можно вынести. Только в этом случае всеравно константа будет в памяти, а не как immediate.
  21. Восклицательный значок убрать в инструкции источника (инкрементор?). Только константа будет длиной разрядности всех регистров (64 байта)
  22. Добрый день. Продолжаю осваивать чип Allwinner V3s. Столкнулся с таким фактом. Нужно сделать переброс "память-память" самым наискорейшим способом, который возможен. Начал ковырять DMA и обнаружил несколько малоприятных вещей: 1) DMA не поддерживает переменные шаги приращения. Только программирование через дескрипторы. 2) Тактовая частота работы DMA всего 200 МГц !!! В сорцах линукса зачем-то для тактовой DMA используют AHB, которая получается делением на 2 частоты ядра: 1200/2 = 600 МГц. Затем эти 600 МГц делятся ещё на 3 для DMA. В итоге выходит всего-навсего 200 МГц. Таким DMA полезно делать только подкачку аудио-данных при воспроизведении или записи звука. Или ещё что-нибудь свя занное с забором-выводом данных в периферию! Для быстрого коприрования память-память не подходит! А теперь о хорошем! Если копировать с помощью инструкций NEON: void MEMCPY(u8 *dst,u8 *src,u32 size) { asm volatile( "1: \n" "VLDM %[src]!,{d0-d7} \n" "VSTM %[dst]!,{d0-d7} \n" "SUBS %[size],%[size],#0x40 \n" "BGT 1b \n" : [dst]"+r"(dst), [src]"+r"(src), [size]"+r"(size) : : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "cc", "memory" ); } то скорость получается самая максимальная. Если битовое поле TEX выставить равным "001", то получим ещё более высокий прирост в скорости (+20 %): //VIDEO MEMORY i=61; mmu_tlb_address[i + (dram_base>>20)] = (dram_base + (i << 20)) | (0 << 19) | (0 << 18) | (0 << 17) | (0 << 16) | (0 << 15) | (1 << 12) | //TEX (3 << 10) | (0 << 9) | (15 << 5) | (0 << 4) | (0 << 3) | //Cache (1 << 2) | //Buffer (2 << 0); При этом бит кеширования в дескрипторе приёмника в MMU-таблице должен быть выключен! Если его включить в приемнике, то скорость просядет. Тоесть: приемник: TEX=1, C=0, B=1 источник: TEX=0, C=1, B=1 При таком раскладе выходит около 8000 FPS при копировании буфера 240 x 160 x 16 бит. (ядро 1200 МГц, память 456 МГц ). С DMA выходит в 8 раз меньше! Если увеличить частоту DMA в 2,3 раза, то скорость нисколько не увеличивается. Действительно ли с DMA всё так печально, или есть способ его заставить работать быстрее?
  23. Идейно я его превзошёл, а вот финансово - нет. Но для меня это не главное. V3s будет лучше, чем F1C100S хотя бы из-за размера памяти вдвое. Она понадобится для запуска РОМов от эмуляторов CPS и NEO-GEO. Эзернет также как USB у меня в нон-грате. Так исторически сложилось, что не могу им найти применение. Скачать исходники u-boot на ваш камень. Затем долго медитировать и взять из них код, нужный вам. Слепить проджект и сбилдить. Но в убуте нет работы со звуком. Выручили даташит и линукс. В финале, должна прийти мысль, что оллвиннеры не сложнее STM32