24-битный цвет. Есть ли другие решения?, Ну очень неудобный формат. Опции

[DpInRock]

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

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

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

[DpInRock]

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

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

[aaarrr]

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

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

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