Видеокарта перестаёт быть пригодной к работе не тогда, когда изнашивается кремний, а тогда, когда под неё перестают выходить драйверы. Это программная граница, и наступает она предсказуемо, по внутреннему графику производителя, а не по состоянию железа. Понимание того, как устроен этот график и какие стадии он проходит, позволяет заранее оценить остаточный срок службы конкретного поколения, а не выяснять это в момент, когда очередное обновление системы отказывается ставить драйвер.

Из чего вообще состоит драйвер

Драйвер видеокарты — не один модуль, а стек. В нижней части находится ядровая часть: управление памятью, планировщик задач для графического процессора, обработка прерываний, режимы энергопотребления. Выше лежит пользовательская часть, где живут реализации графических интерфейсов — компилятор шейдеров, трансляция вызовов интерфейса в команды конкретной архитектуры, слои вычислительных интерфейсов. И отдельно существует прошивка на самой карте, обновляемая редко и обычно только на этапе производства.

Разделение объясняет, почему поддержка заканчивается не единомоментно. Ядровая часть остаётся совместимой с операционной системой довольно долго, а пользовательская — та, которая переводит вызовы новых версий графических интерфейсов в инструкции архитектуры, — устаревает быстрее. Именно она первой отказывается принимать код, написанный под возможности, которых в архитектуре карты просто нет.

Стадии жизненного цикла

Первая стадия — актуальная ветка. Карта получает те же обновления, что и новые модели: оптимизации под свежие приложения, исправления ошибок, поддержку новых функций интерфейсов. Выпуск идёт с высокой регулярностью.

Вторая стадия — перевод в отдельную ветку для устаревших архитектур. Формально драйверы ещё выходят, но содержат только исправления ошибок и уязвимостей. Ни оптимизаций под новые приложения, ни новых возможностей туда уже не добавляют. С этого момента разрыв в производительности между картой и её ровесниками из актуальной ветки начинает медленно расти: новые движки написаны с расчётом на пути исполнения, которых в старой ветке никто не дорабатывает.

Третья стадия — только критические исправления, с редкими выпусками и без гарантий по срокам. Четвёртая — архив: последняя версия остаётся доступной для загрузки, новых не будет. С этого момента любое изменение в окружении — обновление ядра операционной системы, смена модели безопасности, новая версия графического интерфейса — становится риском, который никто не будет устранять со стороны драйвера.

Что ломается на практике

Первым обычно отваливается не сама графика, а совместимость с новыми версиями интерфейсов. Приложение, собранное под свежую версию графического или вычислительного интерфейса, при запуске проверяет уровень поддержки и либо переключается на резервный путь, либо отказывается стартовать. Второй типичный отказ — обновление операционной системы. Модель драйверов меняется поколениями, и когда система переходит на новую, для старой архитектуры драйвер под неё уже не собирают: карта либо работает на базовом видеоадаптере без ускорения, либо система отказывается устанавливаться.

Третий сценарий — аппаратное декодирование видео. Блок декодера умеет ровно те кодеки, что заложены при проектировании, и никакое обновление драйвера не добавит новый формат. Появление нового распространённого кодека означает, что декодирование ляжет на центральный процессор, с соответствующим ростом нагрузки и энергопотребления; связанные с этим требования разбираются в разделе про процессоры.

Четвёртый сценарий менее очевиден — профессиональные приложения. Пакеты трёхмерной графики и монтажа проверяют версию драйвера и наличие вычислительных возможностей определённого уровня. Программа с обновлением может просто перестать видеть карту как ускоритель и переключиться на программный расчёт.

Отдельный случай открытых драйверов

В экосистеме открытых драйверов картина другая. Код поддержки старых архитектур остаётся в общем дереве и продолжает собираться вместе с ядром и графическим стеком годами после того, как активная разработка под конкретное поколение прекратилась. Активной оптимизации нет, но и резкого обрыва тоже: карта продолжает работать с базовым ускорением и с тем уровнем графического интерфейса, до которого её довели. Иногда поддержка старой архитектуры всё же удаляется — обычно после того, как поддерживать её код становится дороже, чем польза от него, — но происходит это с предупреждением и через несколько циклов выпусков.

Как оценивать остаточный срок

Практических ориентиров несколько. Стоит смотреть на дату выхода архитектуры, а не конкретной модели: в одну ветку поддержки попадает всё поколение целиком, включая карты, которые продавались годы спустя под другими названиями. Полезно отслеживать, в какой ветке драйверов находится карта прямо сейчас и какая частота выпусков у этой ветки — переход от ежемесячных к редким выпускам служит достаточно надёжным сигналом.

Отдельно оценивается требуемый уровень графического интерфейса для тех приложений, которые реально нужны. Если карта поддерживает нужный уровень аппаратно, она останется работоспособной и после того, как драйверы перестанут обновляться; если приложения уже требуют более высокого уровня, ситуация не улучшится ни при каких обновлениях.

И последнее: конец поддержки не превращает карту в неработающую. Она продолжает выводить изображение и выполнять всё, что умела, на зафиксированной версии драйвера. Проблемой это становится в момент, когда обновляется что-то ещё — система, приложение, формат данных, — и восстановить совместимость становится нечем. Планировать замену разумно именно от этой точки, а не от снижения производительности.