Сравнительный анализ качества драйверов от ATI, Matrox и NVIDIA В настоящее время ведущие производители видеокарт для большинства своих моделей предлагают драйвера для Linux, а в отдельных случаях – для xBSD. Вот только качество этих драйверов далеко не на высоте и без танцев с бубном при установке и использовании не обойтись…
Монстры в зоопарке Никсовая модель разработки драйверов радикально отличается от принципов системного программирования под Windows. Зоопарк UNIX-подобных систем требует совершенно иных подходов, вовлекающих в процесс разработки драйвера создателей самой операционной системы. Без их поддержки драйвер обречен на поражение.
При всем многообразии Windows-систем (драйверная модель которых многократно менялась даже в рамках линейки NT) количество их хоть и велико, но конечно. Всякая система дана нам в виде законченного набора двоичных модулей, обладающих вполне предсказуемыми свойствами. В никсах же все зыбко, здесь ни на что нельзя положиться. Продвинутый пользователь может скомпилировать монолитное ядро без поддержки модульности (а это значит, что драйвера должны быть представлены в виде исходных текстов, включенных в общее дерево ядра). Системные вызовы варьируются от системы к системе, поддерживают множество моделей перехода с прикладного уровня на уровень ядра (далекий вызов по селектору 07h, прерывание 80h, машинная команда SYSENTER) и допускают изменение соглашения о передаче параметров – через стек или регистры…
UNIX-сообщество не прилагает существенных усилий для облегчения жизни сторонним создателям драйверов. И препятствует распространению закрытых бинарных драйверов, работающих только под той версией UNIX'а, для которой они были созданы. UNIX way – это открытые тексты, адаптируемые создателями дистрибутивов с учетом всех внесенных ими изменений в код ядра, высокоуровневых библиотек-оберток вокруг системных вызовов и т.д. Таким образом, при всем нежелании коммерческих разработчиков расставаться с исходными текстами – другого пути попросту нет. Всякие попытки обойти фундаментальные особенности UNIX-систем рождают монстров, от которых не в восторге ни составители дистрибутивов, ни конечные пользователи.
Но довольно слов! За дело! Рассмотрим, какие подходы исповедуют ведущие разработчики: ATI, NVIDIA, Matrox – и чем они порочны.
ATI Не драйвера, а гигантские циклопические сооружения, занимающие в упакованном виде порядка 50 Мб! Это создает определенные проблемы даже для пользователей ADSL, не говоря уже о диалапщиках. И что же находится внутри чуда инженерной мысли с расширением .run? Оказывается, файл представляет собой короткий shell-скрипт. К нему дописан gzip-архив, проверяемый на предмет целостности этим самым скриптом, с последующей распаковкой и передачей управления на пусковой файл (если проверка прошла успешно).
При желании run-файл можно распаковать и руками. Грузим его в любой hex-редактор и находим последовательность «1F 8B 08 00», выделяя блок отсюда и до EOF. Сохраняем его на диск, меняя расширение на .gz, натравливаем gzip (или любой другой совместимый с ним архиватор). Затем извлекаем оттуда .tar, который и разворачиваем на диске со всей иерархией директорий, что там имеется.
В корневом каталоге архива находится огромное количество .sh-файлов, из которых нас в первую очередь интересуют ati-installer.sh, postun_drv.sh, post_drv.sh и pre_drv.sh, отвечающие за определение версии системы, сборку и установку драйверов.
Сами драйвера поставляются в виде «полуфабриката» – откомпилированных so-библиотек, расположенных в каталогах /x710, /x690, /x680 (для 32-разрядных версий) и /x710_64a, /x690_64a, /x680_64a (для 64-разрядных версий). Как легко заметить, за этими «магическими» цифрами скрывается модель видеокарты (и, в зависимости от типа драйвера, эти цифры могут варьироваться в очень широких пределах). Однако помещать в один архив драйвера для разных видеокарт не есть хорошо, тем более что каждый из каталогов (а их у нас шесть!) в неупакованном виде тянет на десяток мегабайт.
Дальше начинается самое интересное. «Полуфабрикаты» собираются на конечной машине, линкуясь при помощи стандартного линкера ld (в дистрибутивах, заточенных под начинающего пользователя, его обычно нет). При этом возникает проблема определения версий стандартных библиотек (типа libc) и путей к ним. Она решается эвристическим путем, реализованным в процедуре DetectLIBC (см. файл ati-installer.sh, который, к слову, содержит довольно много ошибок).
Парни из ATI (судя по всему) не знают, что линковать модули можно не только с помощью линкера, но и компилятора gcc, который уж точно знает, какие библиотеки у нас установлены и где их искать. Впрочем, на целевой машине gcc может и не быть, так что подход разработчиков в чем-то оправдан. Если ты нарвался на ошибку линкера, ругающегося на ненайденные библиотеки/пути, можно заглянуть в вышеупомянутые скрипты и пофиксить проблему вручную.
Системно-зависимый код вынесен в директорию /packages, из которой следует, что в настоящий момент ATI поддерживает следующие дистрибутивы: /Debian, /Fedora, /Mandriva, /RedFlag, /RedHat, /Slackware, /SuSE и /Ubuntu. Они отличаются друг от друга, главным образом, абсолютными путями и «родимыми пятнами» (например, в Ubuntu это способ запуска программ из-под root'а). Все системно-зависимые файлы представлены в текстовой форме (скрипты) и при возникновении терок с конкретным дистрибутивом сравнительно легко правятся более или менее продвинутым пользователем. Кстати, обращает на себя внимание интернациональный состав разработчиков драйвера. Комментарии к скрипту для /Slackware написаны на французском языке, остальные — на английском.
«Полуфабрикаты», собираемые на целевой машине (при всех минусах такой схемы), – это большой шаг вперед для инженеров из ATI. Раньше было еще хуже. Возле ссылки на драйвер красуется горделивое примечание: «Notes: The above drivers support English only. The display driver requires POSIX shared memory to be enabled on the system. Kernel Source package is no longer required if Kernel Header package is installed». Отсюда следует, что теперь установщику требуются лишь заголовочные файлы, а не полные тексты ядра, которые зачастую отсутствуют даже на девелоперских машинах!
Библиотеки-полуфабрикаты изначально закладываются на вполне конкретные архитектурные особенности, что ухудшает их совместимость с нестандартными ядрами. Не говоря уже о том, что от ядра требуется поддержка модульности (упрощающая внедрение rootkit'ов) и, вообще, гарантий, что драйвер встанет «влет», у нас нет никаких. И стоило ради этого качать 50 метров?
NVIDIA Сабжевая фирма также использует run-формат (для Linux систем) и простой gzip-архив (для FreeBSD), каждый из которых занимает ~13 Мб, что намного лучше, чем у ATI. В комплект поставки входит подробная документация в формате man и html, в неупакованном виде занимающая ~1 Мб с описанием возможных проблем и путей их решения. На этом благопристойности и заканчиваются. Дальше начинается сплошной мрак.
Каталог /usr/src вместо исходных текстов содержит заголовочные файлы, двоичный загружаемый модуль ядра nv-kernel.o и предкомпилированные бинарники (из подкаталога precompiled), специфичные для каждой конкретной версии Linux'а. В частности, дистрибутив RedHat'а насчитывает 78 версий. Другие дистрибутивы – чуть меньше, но проблема не в количестве, а в самом факте наличия системно-зависимых файлов. Они представляют собой обычные объектные модули в ELF-формате, слегка искореженные разработчиками, впендюрившими свой логотип перед ELF-заголовком. Чтобы «скормить» файл дизассемблеру, необходимо открыть его в hex-редакторе, найти строку «ELF», выделить блок до EOF и сохранить его в нормальный объектный модуль, который теперь можно хачить, исправляя ошибки разработчиков. После чего проделать обратную операцию, вернув заголовок на место.
В драйвере для FreeBSD директории precompiled, естественно, нет, поскольку, FreeBSD – она одна (зоопарка клонов здесь нет). Точнее, это парни из NVIDIA думают, что она одна, забывая о различных версиях и нестандартных ответвлениях, не говоря уже о NetBSD и OpenBSD, где все совсем по-другому. Самое смешное, что даже во FreeBSD-версии драйвера присутствует множество «не вычищенного» Linux-кода.
Несмотря на то, что качество NVIDIA-драйверов намного выше, чем у ATI (NVIDIA учитывает многие неочевидные тонкости ядра), с совместимостью дела обстоят кошмарно. Драйвер либо ставится автоматом, либо не ставится вообще, и чтобы заставить его работать, необходимо сменить версию Linux (FreeBSD). Или, при наличии опыта, попытаться захачить двоичные файлы, разобраться в которых намного труднее, чем в текстовых скриптах от ATI.
Вывод: при всей моей антипатии к ATI (о вкусах не спорят, это дело личное и, можно даже сказать, интимное) лучше все-таки скачать 50 метров всякого мусора, чем ковыряться в двоичных файлах от NVIDA, рискуя потерять совместимость при обновлении версии ядра. С другой стороны, если драйвер от NVIDIA работает, то он работает, а не глючит – что частенько случается с продукцией от ATI. Короче, как и везде, имеется проблема выбора наименее худшего из двух зол.
Matrox Компания Matrox (которой мыщъх оставался верным на протяжении последних десяти лет) максимально приближена к философии UNIX'а, однако, не выдержав конкуренции в бытовом секторе, она сосредоточилась на промышленном (в частности, поставляет видеокарты для медицинского оборудования). Это положительно сказалось на качестве кода.
Размер gzip-архива с драйверами составляет всего-то 3 Мб. Рядом лежит архив с полным набором «честных» исходных текстов – чуть больше 2 Мб. Красота! Наличие сорцов позволяет пофиксить любые ошибки (одна из которых заключается в попытке повторного освобождения уже освобожденной памяти – обнаружена мной в ходе разборов спонтанно возникающих глюков). Исходные тексты (не без переделок, конечно) могут быть встроены непосредственно в ядро, откомпилированное без поддержки модульности. Поддержкой новых (или древних) версий может заниматься любой энтузиаст, а не только компания-производитель, и для этого совершенно необязательно копаться в двоичном коде.
В конце концов, Matrox производит и продает видеокарты, а не программное обеспечение. Какой смысл зажимать исходные тексты, если там все равно нет ничего интересного? К тому же, выдрать ноу-хау (если предположить, что такое там имеется) – не такая уж сложная и дорогостоящая задача.
Впрочем, мы отвлеклись. Вернемся к нашим матрасам, тем более что все их достоинства на этом заканчиваются. Предоставляя исходные тексты, компания не заботится о поддержке зоопарка Linux-систем и перекладывает решение этой задачи на плечи конечного пользователя. В readme файле так прямо и написано: мы используем абсолютные пути из Red Hat Linux 9.0, а если у вас они отличаются (как, например, в Ubuntu), то… берите исходные тексты и правьте их самостоятельно или создавайте символьные ссылки в своей файловой системе. Короче, делайте, что хотите, только не трогайте нас!
Но пути – это ладно, исправить их – минутное дело. Куда хуже то, что Matrox поддерживает ограниченное количество версий X'ов. В частности, драйвер для видеокарт G200/G400/G450/G550 работает только с X.org версий 6.7.0, 6.8.0, 6.8.1, 6.8.2, 6.9.0 и 7.0.0, а все прочие уже требуют довольно радикальной правки исходных текстов (и, соответственно, опыта разработки драйверов для Linux/BSD). Учитывая невысокую популярность продукции Matrox на массовом рынке, этим никто за просто так заниматься не будет. Разве только при установке Matrox на промышленное оборудование, вокруг которого крутятся огромные деньги и тусуется множество грамотных специалистов. Впрочем, пионеров тоже хватает (как и в любой индустрии).
Кого хочешь – выбирай… На каком же вендоре стоит остановить свой выбор? Вопрос неоднозначен и зависит от специфики решаемой задачи. В критических инфрастуктурах (или домашнем компьютере, владелец которого каждую перезагрузку ощущает чуть ли не как физическую боль) лучше всего использовать видеокарты от Matrox (если только их удастся найти), но прежде чем драйвера встанут в строй, над исходными текстами придется пыхтеть не одну ночь. Зато мы получим именно то, что нам нужно (например, монолитное ядро, рекомендуемое к использованию в серверах). Без опыта программирования драйверов под Linux/FreeBSD за Matrox лучше не браться (за исключением тех случаев, когда заданная конфигурация явным образом поддерживается драйвером).
ATI – это «микрорайон», состоящий из большого количества сборных домиков, построенных в стиле: «не нравится — пересобери сам». Количество поддерживаемых дистрибутивов довольно велико. Поэтому править скрипты вручную приходится лишь относительно небольшому числу «счастливцев», обладающих «не той» версией Linux/FreeBSD. Впрочем, установка драйвера по-любому требует инструментов разработки и заголовочных файлов ядра, отсутствующих во многих дистрибутивах. Это существенно увеличивает объем скачиваемых файлов, а трафик, он, как известно, денег стоит (даже на безлимите, потому как время – те же деньги).
NVIDIA вызывает довольно противоречивые чувства. Качество драйверов намного выше, чем у ATI (но ниже, чем у Matrox). Количество поддерживаемых версий Linux тоже будет повыше, чем у ATI. Увы, если текстовые скрипты ATI позволяют справиться с проблемой, что называется, «на лету», без отрыва от распития пива из кружки с надписью «root», то захачить двоичные файлы, «заботливо» предоставленные NVIDIA, сможет только продвинутый хакер – да и то, не без матюгов.
Короче, нет в мире совершенства. Ожесточенная конкуренция положительно сказывается на ассортименте и качестве *nix-драйверов – но кто первым выпустит «правильный» драйвер, можно только гадать. До полностью автоматической установки драйвера еще далеко, и поддержка Linux (не говоря уже о BSD-подобных системах) по-прежнему представляет собой огромную головную боль, частично снимаемую армадами хакеров и продвинутых пользователей. Если отбросить Matrox, то ATI больше ориентирована на опытных пользователей, а NVIDIA – на «домохозяек» или мега-хакеров, способных разобраться в двоичном коде. У каждого бренда свои проблемы, и идеального производителя не существует.
Решение проблем установки ОК, драйвер скачан, но его установка проваливается (или новые графические режимы и возможности акселерации остаются незадействованными). Что делать?! Самое простое – забросить Linux, вернувшись на Windows (где таких проблем просто нет). Ведь, если человеку нужен графический десктоп (со всякими там ускорениями и эффектами прозрачности), то, значит, в философию Unix он не вкурил, и ему нужна еще одна Windows, только не такая как у соседа, а более крутая. Скажите, что мешает работать в VESA-режиме и псевдотекстовом консольном режиме, поддерживаемом всеми видеокартами без исключения?
Если же все-таки хочется графических наворотов, – что ж! Первым делом следует внимательно прочитать руководство по установке драйвера (установив пакет программ для разработчика и заголовочные файлы ядра, если они не были установлены ранее). Затем изучить on-line справку и FAQ по установке. В 9 из 10 случаев там содержится либо решение проблемы, либо некий work around («обходной путь»). Наконец, можно обратиться в отдел поддержки, подробно описав ситуацию (только не стоит ждать быстрого ответа), или немного погуглить в Сети.
Гарантий, что проблема имеет решение, естественно, никаких. Особенно, если пытаться подружить передовую модель видеокарты с древней версией Linux (равно как и наоборот). Скорее всего, нам предложат сменить систему или карту – *nix-системы всегда славились своей «дружелюбностью» к потребителям.
INFO Свободный драйвер для видеопроцессоров Intel (xf86-video-intel) не был рассмотрен, поскольку автор не имеет ни одного компа с интегрированным видео от Intel.
Линкер (компоновщик) связывает и объединяет ассемблированные объектные файлы в исполняемую программу.
Официальные драйвера от NVIDIA используют свой способ доступа к видеокарте и не нуждаются в DRI (Direct Rendering Infrastructure обеспечивает прямой доступ к видеокарте и функциям OpenGL). Драйвера от ATI и Matrox полностью поддерживают архитектуру DRI.
WWW 
