Есть ли кто-то, кто использует 2D ускоритель в i.mx6?

Суть проблемы такова, что катастрофически не хватает быстродействия блиттинга. Игровая сцена 6400 полностью из спрайтов отрисовывается с частотой ~45 кадров в секунду.

Как отрисовываю: при запуске игры все графические ресурсы загружаются в память, выделенную с помощью g2d_alloc.
Сцена отрисовывается в теневом буфере, затем при полной отрисовке теневой буфер копируется в область памяти, где расположен /dev/fb0

Заметна просадка, когда на экране достаточно много мелких деталей (спрайтовые шрифты). Сейчас изменяю код, чтобы маленькие текстуры отрисовывались силами процессора и memcpy, а уже большие полотна, особенно с прозрачностью, отрисовывались с помощью g2d_blit.

Если кто-то работал с этим усорителем, может подсказать, верно ли я вообще использую g2d_blit для отрисовки в /dev/fb0 ? Может есть какие-то более изящные методы отрисовки спрайтовой графики?

Нашёл ответ сам.

Фишка в том, что во всех примерах, что я видел (а их не так и много к слову), фукнция g2d_finish() вызывается после каждого блита, что неверно. Достаточно вызывать её единожды при отрисовке кадра, например у меня это происходит в функции Flip(), в которой содержимое теневого (shadow) буфера копируется в область памяти экрана.

Цитата

верно ли я вообще использую g2d_blit для отрисовки в /dev/fb0

можно убрать лишнее копирование - отрисоывать напрямую в видеопамять фреймбуфера. Сделать виртуальный размер фреймбуфера в 2 раза больше реального, отрисовывать в теневую часть буфера и потом переключать видимую часть через FBIOPAN_DISPLAY в вашей функции Flip() вместо копирования. В буилдруте есть примеры фрискейл

Target packages --->
Hardware handling --->
Freescale i.MX libraries --->
[*] imx-test

посмотрите исходники - там есть примеры с FBIOPAN_DISPLAY.

Цитата

можно убрать лишнее копирование

Спасибо за совет, этот вариант я уже находил.

Тут есть пара затыков:
1) Выделение памяти под framebuffer в таком случае происходит несколько иначе, чем в примерах с g2d, и я не смог получить физический адрес fb0 в таком случае. Возможно, я просто туплю, но

2) есть и второй минус: фреймбуффер у меня 16-битный, чтобы занимать меньше места в ОЗУ и давать больше простора для ресурсов игры, а ресурсы все 32-битные, чтобы поддерживать прозрачность.
В Вашем варианте каждый блит будет с преобразованием 32->16, что увеличит нагрузку. У меня же вся отрисовка сцены идёт в 32-битный теневой буфер, то есть без преобразования, а преобразование в 16 бит идёт только на флипе. Так получается быстрее. Можно фреймбуфер инициализировать в 32 бита, но тогда он будет занимать лишнее место в ОЗУ, и ресурсы могут не поместиться, придется динамически подгружать в процессе игры, а это подарит мне непередаваемые приключения по переделыванию движка - уж так он реализован.

1) С физическим адресом не должно быть проблем

устанвливаете виртуальное разрешение

Цитата

ioctl(fd_fb_bg, FBIOGET_VSCREENINFO, &g_screen_info);

g_screen_info.yres_virtual = g_screen_info.yres * g_display_num_buffers;
if (ioctl(fd_fb_display, FBIOPUT_VSCREENINFO, &g_screen_info) < 0) {
printf("fb_display_setup FBIOPUET_VSCREENINFO failed\n");
return TFAIL;
}
ioctl(fd_fb_display, FBIOGET_FSCREENINFO, &fb_fix);
ioctl(fd_fb_display, FBIOGET_VSCREENINFO, &g_screen_info);

берете физический адрес

Цитата

g_display_base_phy = fb_fix.smem_start;

видеопамять физически непрерывная так что начало второго буфера - это просто смешение от начала базового адреса на размер экрана

2) надо тестировать - чета я сомневаюсь что преобразование rgb 32 бит -> rgb 16 бит вообще как-то повлияет на производительность 2D GPU а вот нагрузку на память снизит

Цитата

надо тестировать

Если упрусь в производительность при увеличении разрешения экрана, то воспользуюсь этим вариантом и отпишусь здесь - может кому-нибудь и пригодится

А пока всё работает и достаточно быстро.