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

[DpInRock]

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

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

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

[DpInRock]

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

[aaarrr]

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

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

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

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