История одной нехватки
Мой ноутбук оснащен 8 ГБ оперативной памяти. В теории этого должно хватать, но на практике всё меняется, стоит открыть два десятка вкладок в браузере, запустить Figma, Slack, документацию и попытаться работать в VS Code. Система начинает «задыхаться» практически сразу. В какой-то момент компьютер входит в состояние глубокого ступора — можно смело идти пить чай, надеясь, что по возвращении интерфейс хоть как-то откликнется.
Очевидный выход — апгрейд RAM. Но здесь я упираюсь в ограничения: свободный слот либо отсутствует, либо бюджет на покупку планки сейчас совсем не кстати. Забавно наблюдать в диспетчере задач, как RAM забита «под завязку», в то время как видеокарта с 6 ГБ видеопамяти прохлаждается без дела, ведь никакой ресурсоемкой графики в моих задачах нет.
Тогда и возник закономерный вопрос: можно ли заставить простаивающую видеопамять (VRAM) взять на себя часть нагрузки по хранению данных?
Почему видеопамять — это не полноценная замена RAM
Сразу расставим точки над «i», чтобы избежать недопонимания. Архитектура работы процессора с оперативной памятью максимально эффективна: прямой доступ через контроллер дает задержки порядка 70 наносекунд.
Видеопамять же находится «за бортом» — на шине PCIe. Любое обращение к ней — это сложная цепочка транзакций, ожидание ответа GPU и возврат данных. Задержки здесь возрастают до микросекунд, что делает использование VRAM в качестве классической оперативной памяти невозможным. Процессор попросту не сможет быстро декодировать инструкции или работать с таблицами страниц из такого хранилища.
Однако есть другой путь: превратить VRAM в сверхбыстрый своп (файл подкачки).
Своп как спасательный круг
Когда запас RAM исчерпан, операционная система начинает выгружать неиспользуемые фрагменты данных на диск. Это стандартный механизм защиты от критического сбоя, который спасает от потери несохраненных данных, но взамен мы получаем катастрофическое падение скорости.
Что, если перенести файл подкачки с медленного накопителя в быструю видеопамять? Даже при том, что VRAM уступает DDR4, на последовательных операциях она превосходит современные NVMe-накопители.
|
Носитель |
Скорость чтения (последовательная) |
Задержка |
|---|---|---|
|
DDR4 RAM |
~22 000 МБ/с |
~70 нс |
|
VRAM-своп (прогноз) |
~3 800 МБ/с |
~12 мкс |
|
NVMe SSD |
~2 400 МБ/с |
~25 мкс |
|
SATA SSD |
~520 МБ/с |
~120 мкс |
Пусть цифры носят ориентировочный характер, но даже такой расклад показывает: VRAM-своп в 5–10 раз быстрее обычного дискового. Для фоновых процессов браузера, которые «просыпаются» лишь изредка, этого вполне достаточно, чтобы избавиться от фризов.
Реализация идеи
Так как ОС воспринимает VRAM лишь через специфические драйверы, нам нужно «обмануть» систему, представив кусок видеопамяти как блочное устройство. В Linux и Windows для этого можно использовать протоколы типа NBD (Network Block Device) или их аналоги, которые позволяют перенаправлять операции чтения/записи на специально написанный сервер, взаимодействующий с GPU через OpenCL.
Браузер, Figma, VS Code...
↕
Ядро ОС (своп)
↕
NBD / WNBD драйвер
↕
Сервер (OpenCL API)
↕ (шина PCIe)
GPUOpenCL здесь выступает идеальным связующим звеном, обеспечивающим кросс-платформенную работу с видеокартами любого производителя.
Подводные камни
Прежде чем пробовать это на практике, стоит учитывать несколько нюансов:
Волатильность. Видеопамять мгновенно очищается при перезагрузке драйвера, уходе в спящий режим или изменении конфигурации мониторов. Система должна иметь страховку в виде обычного файла подкачки на диске на случай краха VRAM-свопа.
Риск «мертвой петли» (дедлока). Если сервер, управляющий свопом, сам выгрузится в созданный им же файл подкачки, система зависнет. Проблема решается принудительным закреплением процесса в оперативной памяти с помощью mlockall().
Конфликт нагрузки. Если вы начнете играть в «тяжелую» игру, GPU будет занят отрисовкой графики, и ваш своп превратится в бутылочное горлышко. Такая схема эффективна только при наличии дискретной графики, которая простаивает.
Гибернация. Обычный режим гибернации Windows несовместим с VRAM-свопом, так как содержимое видеопамяти при отключении питания гарантированно теряется.
Практическая польза
Лично для меня это был бы способ перекинуть «мертвые» вкладки браузера в VRAM. Возврат к ним был бы практически мгновенным по сравнению с текущим ожиданием, когда система пытается вытянуть данные с HDD или SSD. Это не просто цифры в бенчмарках, а реальный комфорт в повседневной работе.
Что уже существует?
Тема не нова: проект vramfs когда-то пытался реализовать FUSE-файловую систему поверх видеопамяти, а GpuRamDrive для Windows позволяет создавать виртуальные диски в VRAM силами CUDA или ImDisk. Это отличные инструменты для тех, кто хочет поэкспериментировать, не погружаясь в написание собственного драйвера.
Итог
Эта идея — удел энтузиастов, у которых «железные» возможности ограничены, а видеокарта большую часть времени отдыхает. Это не панацея и не замена планке оперативной памяти, но в специфических сценариях — отличный способ вдохнуть новую жизнь в старый сетап.
Будет очень интересно услышать мнения тех, кто уже пробовал подобные «трюки». Как система ведет себя под реальной нагрузкой, а не в синтетических тестах?
