Почему SSD не может стать видеокартой

1. Нет вычислительных блоков.
   Контроллер SSD умеет только перемещать данные между NAND‑чипами и шиной PCIe, иногда — сжатие/шифрование на лету. Он не выполняет шейдеры, растеризацию, математику для 3D/ML и т. п.

2. Несопоставимая задержка и пропускная способность.

   • Локальная память GPU (GDDR6/6X, HBM): сотни нс задержки, 500–1000+ ГБ/с (а у HBM — до нескольких ТБ/с) пропускной способности.
   • NVMe SSD: задержка доступа десятки–сотни мкс (в ~1000× больше), последовательное чтение 7–14 ГБ/с на потребительских PCIe 4.0/5.0 моделях, и сильно меньше на случайных доступах.
     Даже если «кормить» GPU данными с SSD, это на порядки медленнее, чем из VRAM — не говоря уже о том, что SSD сам ничего не считает.

3. Драйверная модель ОС.
   Windows (WDDM), Linux (DRM/KMS) и графические API (Direct3D/Vulkan/Metal) ожидают устройство, реализующее графический конвейер в железе. «Подменить» его блоковым устройством хранения нельзя. Можно написать софтверный рендерер, но он будет считать на CPU, а SSD тут лишь медленное хранилище.

4. Нет видеовыходов.
   Чтобы вывести картинку на монитор, нужны специализированные контроллеры и физические порты. У SSD их нет.

Что можно сделать на практике

1) Софтверный рендер (для совместимости, не для скорости)

• WARP (Windows), llvmpipe/SwiftShader (кроссплатформенно) — полностью программные реализации D3D/Vulkan/OpenGL. Они работают на CPU, подходят для тестов/CI/удалённого рабочего стола, но не для игр/сложной 3D‑графики. SSD в этом сценарии лишь хранит данные.

2) Быстрая подгрузка ресурсов с SSD (это реально ускоряет загрузки)

• Современные движки/API используют NVMe как источник данных (текстуры/модели/шейдерные кеши) с «потоковой» подгрузкой. На Windows для этого есть, например, технологии наподобие DirectStorage.
  Важно: это не превращает SSD в VRAM/видеокарту, а лишь уменьшает время загрузок и «стримит» ассеты. Производить шейдинг всё равно должен GPU.

3) «Память по требованию» при недостатке VRAM

• Реализуемо в самих движках: многоуровневый кэш VRAM → системная RAM → SSD с разбиением ресурсов на тайлы (DX12 Tiled Resources / Vulkan Sparse). Это позволяет запускать сцены, «не влезающие» в VRAM, ценой просадок FPS.
  Опять же: GPU остаётся обязательным, SSD — лишь самый медленный уровень.

4) Для вывода «офисной» картинки без GPU

• Есть USB‑адаптеры DisplayLink (внешние «видеокарты»). Рисует CPU, по USB гонится сжатый поток на адаптер → монитор. Подходит для 2D‑рабочего стола, не для 3D.

5) Для вычислений без видеокарты

• Используйте CPU‑библиотеки (SIMD/AVX2/AVX‑512) или iGPU (OpenCL/DirectML/Vulkan compute). Для тяжёлых задач — облачные GPU или внешние eGPU по Thunderbolt.

Частые заблуждения

• «Можно ли расширить VRAM за счёт SSD?»
  Нет напрямую. Настройка файла подкачки/«shared memory» не превращает SSD в видеопамять; это ведёт к фризам из‑за огромной задержки и может увеличить износ при интенсивной записи. (Чтение менее критично, но тоже медленное.)

• «А если написать драйвер „виртуальной видеокарты“?»
  Можно сделать виртуальный адаптер, который внутри вызывает софтверный рендерер на CPU и хранит ресурсы на SSD. Это работает для совместимости, но производительность будет на порядки ниже даже самой простой дискретной видеокарты.

Небольшая оценка «масштабов бедствия»

• Один 4К‑кадр 8‑бит RGBA:
  3840 × 2160 × 4 байта = 33 177 600 байт ≈ 33,2 МБ.
  Для 60 FPS только перенос «готовых» кадров — ≈ 2 ГБ/с.
  Но реальный рендер требует сотен–тысяч операций на пиксель, доступов к текстурам и буферам — это уже домен GPU с сотнями–тысячами ГБ/с к VRAM. SSD тут помочь не может.

Вывод

Создать видеокарту «из SSD» невозможно: не хватает вычислительных блоков, неподходящие задержки/скорости и несоответствие драйверной модели. SSD может ускорять загрузки и стриминг данных, но не заменять GPU.