Пару месяцев назад разработчик задался странным вопросом: почему Emacs рисует текст через CPU, а не GPU. Он нырнул в код и понял, что вся перерисовка — символы, подчёркивания, скролл — пересчитывается процессором. Редсплей-движок (xdisp.c) создавался в эпоху, когда другого выбора не было.
Он решил это исправить. В итоге получил полноценный display-бэкенд для macOS на Metal и второй — для GNU/Linux на OpenGL, с видеоплеером внутри буфера, шейдерными эффектами курсора и сотней сообщений в рассылке Emacs. Разработка велась с помощью LLM-копайлота, и это стало главным сюжетным поворотом.
Архитектура — трёхслойная. Вся логика рисования живёт в нейтральном файле на чистом C (gfxterm.c), без привязки к платформе. На каждую платформу — драйвер с ~25 примитивами вроде «загрузи текстуру», «нарисуй квад», «покажи кадр». Первым стал драйвер Metal на macOS. Золотое правило: xdisp.c не трогать. Редсплей считает glyph-матрицы как всегда, разработчик только подключается к существующему интерфейсу рисования.
Проблема оказалась в pixel parity. Успех означал, что картинка совпадает с Cocoa-бэкендом пиксель в пиксель. Разработчик собрал тестовый стенд: запускал два Emacs, снимал скриншоты, сравнивал через Python и PIL. Всплыли тонкости: разная антиалиасинг-настройка, неверный цвет рельефных границ, off-by-one в вертикальной позиции глифов.
Самый поучительный баг — курсор. Разработчик добавил анимации: расширяющееся кольцо, кометный след. Они работали, пока он печатал. Как только ввод прекращался, анимация застывала. Виноват CADisplayLink — он умирает в покое. Решение — вынести всё непрерывное в Lisp-таймер, который тикает периодически и командует драйверу «продвинь всё и покажи кадр не чаще раза». После этого macOS-бэкенд стал идеальным.
Когда бэкенд собрали, пришло время добавлять вещи, доступные только GPU: видео в буфере, шейдерные эффекты курсора, cross-fade при переключении буферов. Разработчик даже собрал tiny YouTube-фронтенд внутри Emacs.
Самое интересное началось, когда он отправил патч в emacs-devel. Sean Whitton сразу спросил: «Это не LLM-сгенерированное?» Разработчик честно ответил: «100% создано с LLM». Ответ был вежливым и окончательным: GNU-проект не принимает LLM-сгенерированные вклады. Патч не приняли. Но это не закрыло тему, а развернуло её в три стороны.
Dmitry Gutov предложил считать код «предметом для изучения». Richard Stallman выступил с моральной позиции: GPU — это катастрофа для свободы ПО. Arsen Arsenović возразил: Vulkan и OpenGL можно реализовать софтверно (Mesa), никакой неволи нет. Eli Zaretskii заметил, что без перепроектирования редсплей-движка выгода от GPU невелика.
Разработчик пошёл по плану, написанному сообществом: написал второй драйвер — OpenGL на GNU/Linux с EGL и FreeType. Вся логика из нейтрального слоя переиспользовалась без изменений. Драйвер заработал пиксель-в-пиксель против GTK/cairo. Но Linux принёс новый ад: ghost-изображения из XDBE-буфера.
Бенчмарки на ноутбуке с AMD Radeon (Renoir) показали: на HD-экране GPU отстаёт от cairo при вводе текста (1311 fps против 1857). Но на 4K всё переворачивается: GPU быстрее в 2–11 раз. Цена cairo растёт линейно с пикселями; GPU почти не двигается. Видео, эффекты и скролл при высоком разрешении — вот где GPU реально нужен.
В итоге патч не примут, и это нормально. Разработчик использует форк с флагом --with-gpu. Он вынес из проекта архитектурный опыт, технические шрамы и — неожиданно — честный разговор о производительности, свободе ПО и роли AI в коде. Финальный совет: делайте эксперимент, который вас одержим, даже если он не закончится там, где вы ждали. Код лежит на github.com/tanrax/emacs-gpu.