[GenaSPB 11]

Я не понял необходимости делать выравнивание на 4к

И оьеспеченв ли крвтность 16 байт ращмер строки исходного имеджа.

Ещё... какая тактовая у модуля g2d? У меня 300 МГц. Выше 400 сбоит

Изменено 10 марта пользователем GenaSPB

[mantech 42]

3 часа назад, GenaSPB сказал:

Я не понял необходимости делать выравнивание на 4к

Просто при разметке памяти сделал подобные буфера, для jpeg декодера нужна такая кратность, например.

3 часа назад, GenaSPB сказал:

какая тактовая у модуля g2d? У меня 300 МГц.

У меня по моему 250.

 

Еще заметил такую шляпу, особенно заметно на фулл ХД разрешении, если перекидывать полноэкранную картинку в экранную область используя G2D, то получаю неприятную гребенку на экране во время выдачи, время поворота в экранную область занимает 12-14 мсек. Если использовать ожидание синхронизации кадра, то эта гребенка появляется в правом нижнем углу, если не исп. - то где попало. Если делать поворот в буфер и из него просто копировать в экранку, то вместо гребенки получаем проскакивающую полосу, что чуть более эстетично, но тоже не айс, но самое удивительное, что то же самое используя НЕОН, тоже с синхронизацией по кадру, работает чуть медленнее, 20мсек примерно, но ничего подобного на экране нет, то-ли потому, что НЕОН копирует более мелкими блоками, или это как-то синхронизируется с разверткой, что в глаза не бьет...

Да, сейчас предложат второй буфер и переключать между ними, но увы и ах, еще "лишние" 8 Мбайт мне для этого жалко)))

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

[repstosw 18]

On 3/10/2024 at 4:21 PM, mantech said:

Если использовать ожидание синхронизации кадра, то эта гребенка появляется в правом нижнем углу, если не исп. - то где попало. Если делать поворот в буфер и из него просто копировать в экранку, то вместо гребенки получаем проскакивающую полосу, что чуть более эстетично, но тоже не айс, но самое удивительное, что то же самое используя НЕОН, тоже с синхронизацией по кадру, работает чуть медленнее, 20мсек примерно, но ничего подобного на экране нет, то-ли потому, что НЕОН копирует более мелкими блоками, или это как-то синхронизируется с разверткой, что в глаза не бьет...

Да, сейчас предложат второй буфер и переключать между ними, но увы и ах, еще "лишние" 8 Мбайт мне для этого жалко)))

🤣🤣🤣

Ну не успевает он отрисовать за время VBLANK, поэтому и видите полоску сверху (или снизу, если полярность синхронизации проинвертирована).

Попробуйте в настройках TCON пересчитать времянки так, чтобы увеличить ширину VSYNC-пульса.  Или грубо FPS в 2 раза меньше сделайте.

20 мс >> T vblank  

 

И да:  сделайте двойную буферизацию и переключайте адрес отображения видеопамяти (переключать адрес надо по VSYNC или вообще в прерывании от TCON):  пока вы будете смотреть на одну страницу,  во второй процессор будет рисовать.

И времени будет всяко-больше, до следующего обновления дисплея.

 

P.S. У меня во всех приложениях работа с отображением графики строго синхронна с обновлением дисплея

[mantech 42]

2 часа назад, repstosw сказал:

сделайте двойную буферизацию и переключайте адрес отображения видеопамяти

Так я написал, что жалко выделять еще 8Мбайт в ущерб РАМ-диска. К тому же отрисовка НЕОНом решила проблему полосок и ступенек при отрисовке, тут как в рекламе - если результат тот же, зачем платить (выделять памяти) больше)))

А вот с поворотом в память, как писал выше, не экспериментировали? 

2 часа назад, repstosw сказал:

Или грубо FPS в 2 раза меньше сделайте.

Там и так 40Гц стоит, меньше будет мерцать экран...

[GenaSPB 11]

Есть же в de регистр информирующий о начале кадра. Просто переписываете в vi или ui новый алрес буфера для отображения и всё .. никаких мерцаний. Всю подготовку делать off screen

[repstosw 18]

9 hours ago, mantech said:

А вот с поворотом в память, как писал выше, не экспериментировали?

Пока занят более приоритетными задачами.

[mantech 42]

9 часов назад, GenaSPB сказал:

Всю подготовку делать off screen

 

12 часов назад, mantech сказал:

Так я написал, что жалко выделять еще 8Мбайт в ущерб РАМ-диска.

 

[GenaSPB 11]

Значит опять выбрали неправильную платформу, если кроить приходится

Вообще то видеобуфер 800*480*4 = 1,536,000 байт, а не 8 мегабайт

Изменено 12 марта пользователем GenaSPB

[mantech 42]

1 час назад, GenaSPB сказал:

Вообще то видеобуфер 800*480*4 = 1,536,000 байт, а не 8 мегабайт

Все правильно, если не расбрасываться на необязательные вещи, и фулл ХД - это не то же самое, что 800х480. При таком маленьком разрешении время перекидывания картинки НЕОНом занимает менее 5мсек, там аппаратно, кроме видеопотоков в реальном времени, вообще ничего делать не нужно, ИМХО...

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

[GenaSPB 11]

Мерцвния при рендинге картинки вилны и на малых разрешениях

[mantech 42]

34 минуты назад, GenaSPB сказал:

Мерцвния при рендинге картинки вилны и на малых разрешениях

Не знаю, что у вас за задача, но у меня терминал раньше работал на 1366х768, что существенно выше вашего разрешения, все работало программно, декодеры картинок, работа с экраном, формы GUI, анимация и пр. и ничего не моргало и не полосило...

С 3D не работал.

[Robotector 0]

Хочу поинтересоваться у автора, как он программирует под эти китайские камни? Попадалась на али платка с f1c200s, но из документации на неё только мануал с регистрами. Я правильно понимаю, что китайцам доступно больше документации, только они её никому не дают?

[GenaSPB 11]

Разбирательство с линукс исходниками. И некоторые догадки.

[Robotector 0]

А линукс и стандартную библиотеку под камни откуда брать? В открытом доступе или ими китайцы тоже неохотно делятся?

[GenaSPB 11]

Github... например тут - DWtiangu/longan-t113-linux-5.4: linux kernel for longan t113 (github.com)

7 minutes ago, Robotector said:

стандартную библиотеку под камни

Стандартная библиотека под камни вполне из arm-none-eabi компилятора есть.
Обслуживание периферии в bae metal - по даташиту, портированием и разбирательством.

Изменено 12 марта пользователем GenaSPB