"Карта" вообще подразумевает кусок текстолита и чипы на ней

. Как правило на "карте" собрана относительно самодостаточная конструкция, с GPU и локальной памятью, такая конструкция вообще относительно автономна. А вы о одной из составляющих aka GPU - графическом сопроцессоре. У ежевики он в этом смысле тоже есть, хоть и достаточно здорово отличающийся от всех остальных. Вплоть до того что у этих извращенцев первым стартует как раз GPU, и уже он из своего кода потом пинает вспомогательный ARM "сопроцессор". Так что ежевика - "GPU с вспомогательным ARMом", а не "ARM с GPU"

. Но кое-что общее у них есть - своей памяти GPU не имеет и по этому поводу для нужд оного отпиливается кусок системной DRAM. Одной из заметных статей расхода в этом регионе является упомянутый "буфер кадра" из которого "CRTC" долбит на экран. Ну и внутренние нужды GPU. Ибо GPU - это кроме всего прочего группа процессоров-числодробилок, которым тоже какую-то память надо в процессе счета. В числодробилки хост вгружает команды и данные, они считают, далее результат или забирается хостом обратно ("GPGPU-вычисления") или выплевывается на экран, если числокрушилки, например, сложат результат в буфер кадра (3D как-то так работает в первом приближении).
В пингвине весь этот зоопарк нынче более-менее попытались подогнать к некоему общему знаменателю, заметив что "CRTC" - как правило достаточно похожи по свойствам, GPU - может быть, а может и не быть, а бывает и так что есть GPU но у него ... нет CRTC

. Да, бывает такая странная штука как GPU без видеовыхода вообще. В некоторых ноутбуках с 2-я видеокартами такое встречается - у одного из GPU может не быть видеовыходов совсем. Вместо этого он спихивает картинку через память второму GPU тот уже ее выдает на экран. В этом случае "буфер кадра" ведет вникуда - его не посещает CRTC. Вместо этого он перекидывается в другой GPU, в том же пингвине по этому поводу сделали достаточно крутую и generic подсистему подпирания таких штук DMA-контроллерами, прямо так и обозвав это начинание - DMA-BUF.
В пингвине этим добром все чаще заведует относительно унифицированная парочка подсистем - Direct Rendering Manager + Kernel Modesettings. Хотя проприетарные драйвера, к сожалению, до сих пор могут иметь свое мнение на этот счет. А упомянутые подсистемы кроме всего прочего позволяют ядру быть немного в курсе текущего видеорежима, спихивают на ядро свойственные ему задачи типа управления памятью и позволяют немного порисовать по минимуму. Как раз в фреймбуферы CRTC-ов. Так что если кому-то надо совсем простой и быстрый доступ, эксклюзивно и пошли бы все другие программы подальше - можно попытаться пристроиться где-то там. Но оно может быть драйверозависимо. Большинство драйверов предоставляют нечто типа "фреймбуфера с наворотами", поверх которого и строится все остальное, но это уже как повезет.
Какие выводы? Для минимального вывода картинки не надо программить GPU - достаточно уметь плевать данные в буфер кадра и выставить видеорежим. Это как правило делает относительно небольшой ядерный модуль, реализующий упомянутые интерфейсы для "своего" железа. Насколько все это захочется делать совсем без ОС - отдельный вопрос

. А вот ускорение вычислений, актуальное для 3D - уже требуют уметь сгенерить код для GPU и прочее. На десктопные GPU кстати интел и амд расперлись спеки выложить, нвидия брыкается, но часть спеков открыла, а вот с мобилочными все печальнее пока. Там возможны варианты. Или использовать бинарный драйвер (где как раз в основном зажат кодогенератор и т.п.) или иногда бывают недопиленные драйвера на основе реверсинга. Pi в этом плане оригинальнее всех - в том плане что его GPU крутит полновесную RTOS и оперирует чуть иначе: ему передают непосредственно исходники шейдеров и данные, он это сам компилирует и запускает, так что проблемы с кодогенерацией не возникает. В том плане что драйвер является довольно простым wrapper для вгрузки всего и вся в GPU, который сам дальше разбирается как самому себе код компильнуть. Наверное при острых приступах мазохизма можно попробовать нечто такое вгружать и без операционки совсем, но на мой вкус это выглядит несколько похожим на Дона Кихота. Все-таки как видим это достаточно сложный комплекс в сумме, драйвера до ума могут доводить месяцами, если не годами...
