Начал программировать графическую подсистему. Цвет - 24 бита, упакованный. (at91sam9261). Т.е. в одном 32-разярядном слове находятся части двух точек (24 бита от одной, и кусок в 8 бит от другой. Может такде 16 бит от одной, 16 бит от другой, а недостающие 8 бит вообще в других словах).

И вот приходится цвет разбивать на RGB составляющие и записывать побайтно.

Вопрос в чем: это так и должно быть или есть какие-то хитрые решения? А то за быстродействие такого подхода боязно маленько.

Правильно - забить на один байт и хранить 32 бита на точку. Потом, в свободные 8 бит положить альфа-канал для любителей украшательств типа полупрозрачных окошек с голыми девочками вместо рамочек.

Нельзя. Я не могу там что-то хранить. Данный формат определен аппаратно. И сделать ничего нельзя.(?)

Уверены? Если да, то метод один - считаем, во сколько регистров лезет целое количество точек (это 3 регистра <=> 4 точки) и работаем с точками группами по четыре, производя все манипуляции непосредственно в регистровых переменных, а затем сливая их в ОЗУ одной командой.

Не уверен, что это даст выигрыш в быстродействии. Вернее, при некоторых БЛОЧНЫХ операциях - конечно даст.
Но нормальные операции, типа, линию провести - потребует дополнительного чтения... А если со сглаживанием - то вообще кранты.

Пробовал поискать какие-то 24-х битные библиотеки, чтоб бросить взгляд - типа, в каком ключе работать, но не нашел.

Единственное придумал, шрифты хранить не побитово. У меня памяти - завались просто. Масса. 256 мегабайт. Вместо бит буду хранить альфаканал - байт. Тогда хоть сглаживание будет может боле-менее на автомате проходить. Хотя не уверен, пока. Не продумывал плотнее.

Нуууу... На все случаи жизни такой рецепт конечно не годится. Хотя, если Вам нужно сглаживание - то без чтения не обойтись. Да и в половине случаев линия будет идти так, что точки будут лежать рядом на одной горизонтали пачками - имеет смысл обработать этот случай отдельно.

Вообще для оценки способов надо посмотреть следующие вещи:

Поддерживается ли вменяемо burst-режим SDRAM - это раз. От этого будет зависить реальная скорость исполнения LDMIA/STMIA.

Два - а не поддерживает ли контроллер кеша в Вашем камне отложенную запись? Если поддерживает - надо смотреть, каким образом, а вдруг побайтный?

С заранее известным фоном - обойдусь и без чтения. У меня без изысков. Все простенько.

Пока не лезу в SDRAM и кэш. Это успеется, когда выхода никакого не будет. Да и не думаю, что это КАРДИНАЛЬНО поможет. Видеостраница в SDRAM. Данные в SDRAM. Буфер звукового кодека - в SDRAM.

Тогда какого хрена Вас интересует, а не будет ли долго, если по байтику писать? Раз уж такой вопрос возник - ознакомьтесь с матчастью в полном объеме. Дело в том что, возможно, встроенный контроллер преобразует четыре побайтных записи в запись одного слова - а значит, что проигрыш при побайтном доступе будет невелик, возможно, что извращаться с пакетной обработкой не придется...

А кеши в любом случае надо включить. В полном объеме (и ICache, и DCache, и Burst, и WriteBack или как их там...). Все-же они кардинально увеличивают производительность (если, конечно, код вменяемый писать).

Ну, кэш в данном случае ничего убыстрять не будет. Ибо он тут нафик не нужен.
Программа работает из внутренней памяти. Разве что шину может малость разгрузить. Да и то - врядли. А проблем от кэша - не так мало, как кажется. И создавать их заранее - пока не вижу смысла.

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

Это, например, каких? С отложенной записью все понятно - надо принимать специальные меры, чтобы данные долелели до железа (актуально для управления периферией). Еще можно наступить на грабли с самомодифицирующимся кодом - тогда велком в мануал на ARM9 и читаем раздел Instruction Memory Barrier.



Эффективные алгоритмы подразумевают под собой не только эффективность самого низкого уровня, но и выше.

Например, в реальной жизни рисование линии под произвольными углами встречается намного реже, чем рисование рамок окошек Следовательно, надо оптимизировать именно эти, вроде бы и крайние, случаи. А они как раз поддаются пакетной обработке (в частности, рисование горизонталей).

Печать символов тоже некисло пакетизируется - для совмещения надо будет прочитать только начало и конец строки, чтобы выполнить наложение, а середину вполне пачками можно копировать из регистров, как я изложил выше.

Про банальное копирование прямоугольников я вообще молчу - тут STM/LDM рулят нипадеццки.

Другое дело, что код, заточенный под выжимку всех соков, имеет вид, как говорят буржуи, "hard-coded routines". Со всеми вытекающими.

Будет, и еще как. Даже из внутренней памяти программа с выключеным кэшем будет работать медленее. Про внешний SDRAM я уж вообще молчу - тут с выключенным кэшем только вешаться.

Да, подумайте, действительно ли нужен режим 24bpp? Мощности у процессора не те, чтобы спокойно работать с упаковаными данными. Хотя на 320x240 может и прокатит.

Босс говорит 24.
С чего вдруг кэш ускорит работу внутренней программы? Под кэш как раз и выделяется часть этой же самой памяти.
А вот замедлять - будет.
А по чтению-записи во внешнюю память по данным - ускорение имеет малый вес. Либо к данным редко обращаюсь, либо это волатильные данные. Не дай БГ их кэшировать.

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


Изучите матчасть и проведите эксперименты, если уж мне не верите. Для фреймбуфера вполне логично использовать кэш в режиме write through, скорость работы с экраном это поднимет в разы. Кэшировать имеет смысл любые данные, просто это нужно делать правильно.

Обратите внимание на стр. 18 даташита. Очень даже выделяется. И именно из internal SRAM.

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

Вообще-то кэш и TCM - это две большие разницы.


Скорость увеличится на запись за счет использования буфера записи.