Введение
Сейчас наверное нет ни одного компьютерного игрока, который бы не знал о таких вещах как драйвер, DirectX и OpenGL. Однако еще десять лет назад эти слова не были столь известны, а наиболее известными драйверами в системе были пожалуй драйверы мыши и дисковода компакт-дисков.
Однако, несмотря на свою нынешнюю "популярность", многие люди достаточно смутно представляют как эти вещи "работают", как связаны между собой и какие роли выполняют.
В данной статье я хочу рассмотреть современное программное обеспечение видеокарт функционирующих на компьютерах под управлением операционной системы Windows, объяснить его основные свойства, принцип работы и назначение. Для этого мы затронем эволюцию видеокарт, неразрывно связанную с ней эволюцию их драйверов и программного обеспечения необходимого для их функционирования в определенных режимах. По ходу наших мыслей мы возможно также отвлечемся на другие косвенно связанные с нашей темой вещи. В завершение я постараюсь ответить на некоторые вопросы связанные с программным обеспечением видеокарт.
Как это было...
Первые IBM PC были оснащены видеоадаптером MDA (Monochrome Display Adapter) предназначенного для вывода исключительно текста. Вскоре за ним последовал CGA (Color Graphics Adapter) принесший с собой, можно сказать, эпохальный для игр графический режим режим 320х200 правда, пока, всего лишь при четырех цветах. Вслед за ним последовал EGA (Enhanced Graphics Adapter) принесший несколько новых режимов среди которых, для игрописателей, наиболее привлекательным был 320х200, но уже при целых 16 цветах. При этом достаточно легко было делать игры с возможностью выбора режима CGA/EGA - разрешение ведь было одно и то же. И вот, наконец, год 1987 - на свет появился VGA (Video Graphics Array) принеся с собой режим 320х200 при невероятных 256 цветах. И опять же, из-за одинакового разрешения, у разработчиков была возможность, по началу, делать игры с выбором видеорежима, на этот раз EGA/VGA. С некоторой натяжкой можно считать что этот режим был популярен в кругах производителей игр целых 10 лет (вспомним хотя бы "Command & Conquer Red Alert", вышедший в декабре 1996).
Отмечу, что в вышеприведенном абзаце приведены конечно не все видеокарты той эпохи. Не упомянуты, например, видеоадаптеры Hercules производства одноименной фирмы, а также видеокарты стандарта MCGA. Однако каких-либо принципиальных отличий в интересующем нас принципе работы от вышеприведенных карт у них не было.
А теперь господа, внимание - все эти карты функционировали без каких-либо драйверов! Да-да именно так. Всё объясняется достаточно просто - разработчики "железа" в то время следовали довольно жестким стандартам описывающим работу графических режимов, иначе говоря, все графические адаптеры, со стороны программы, выглядели одинаково на аппаратном уровне. Стандарт VGA стал стандартом-минимумом для всех видеокарт. С тех пор любая видеокарта должна была поддерживать стандарт VGA, если она рассчитывала на коммерческий успех. Даже сейчас мы пользуемся стандартом VGA до загрузки операционной системы отличной от MS-DOS, а зачастую и после.
Принцип работы видеокарт времён стандарта VGA представлен на рисунке:
программы во времена стандарта VGA обращались к аппаратной части видеокарты напрямую |
После 1987 года, наступило "смутное время" SVGA. Распространено заблуждение что SVGA (Super Video Graphics Array) это тоже стандарт, однако это не так, через термин "SVGA" обозначают все режимы превышающие VGA. Новых стандартов не было. Таким образом не было четко определенного способа как скажем работать в графическом режиме 640х480 при 256 цветах. Нужно отметить, что проблемы была не в "железе", большинство видеокарт как правило могло работать в таком режиме, а в отсутствии стандарта - каждая работала по своему. Таким образом, чтобы обеспечить такой режим работы, нужно было писать свой видеодрайвер для каждой (ну или почти каждой) видеокарты, что большинству разработчиков было не по силам, да и избежать проблем совместимости при этом всё равно было очень сложно. Поэтому очень много игр для MS-DOS по прежнему выпускалось под старый добрый VGA режим 320х200х256.
"Позвольте!" - скажете вы, "А как же... я вот помню - Warcraft 2, Duke Nukem 3D... все они работали под MS-DOS в 640х480 и даже больше!". "Виной", этому VESA (Video Enhanced Standards Association) эта организация по сути продолжила стандартизацию видеорежимов. Стандарт VESA 1.0, появившийся в начале 90-х годов, оговаривал работу в разрешениях от 640х480 до 1280х1024 при 16 и 256 цветах, VESA 1.1 добавил к этому стандарт для работы при 15 и 16 битном цвете (32K и 64K - HiColor), а VESA 1.2 при более знакомом нам 24/32 битном цвете (16,7M - TrueColor) и ввел еще одно разрешение - 1600х1200. Часто в настройках игр эти режимы так и обозначались - "VESA Modes".
VESA режимы также функционировали без каких-либо драйверов, однако требовали наличия VESA BIOS, что впрочем никак не выражалось внешне, т.к. реализован он был тоже на аппаратном уровне. Тем не менее стандарты VESA ограничивали разработчиков "железа" в гораздо меньшей степени чем предыдущие стандарты IBM. Сам стандарт VESA разрабатывался таким образом, что любая существующая карта может быть переделана в VESA-совместимую посредством загружаемого VESA-драйвера, заменяющего собой VESA BIOS. Однако таких драйверов на практике практически не существовало. Вызвано это было тем, что минимум до 1994 года потребности в 640х480х256 режиме не было, а к этому времени все новые разрабатываемые карты поддерживали как минимум VESA 1.0 (а больше, как правило, и не требовалось). К тому же в то время многие не то что не видели, но и не знали, что такое интернет, поэтому привычно "скачать" как это делается сегодня, этот самый VESA-драйвер, даже если бы он вышел, не получилось бы. Хотя конечно существовали и такие монстры как UniVBE (Universal VESA BIOS Extension) предназначенные для эмуляции VESA на старых видеокартах, но к тому времени как в них возникала потребность гораздо дешевле было приобрести полноценную VESA 1.2 карту, которая к тому же была оснащена целыми 2 Мб оперативной памяти.
Принцип работы видеокарты в режиме VESA:
программы во времена стандарта VESA обращались к аппаратной части видеокарты напрямую, правда в редких случаях был нужен драйвер-обманка эмулировавший для программы карту VESA |
Всё многообразие видеорежимов "додрайверной" эпохи представлено в нижеприведенной таблице:
Год | Стандарт | Поддерживаемые режимы |
1981 | MDA | Текстовый режим, черно-белый |
1981 | CGA | MDA; |
1984 | EGA | CGA; |
1987 | VGA | EGA; |
1990 | VESA 1.0 | от 640x480 до 1280x1024 при 16 и 256 цветах |
1993 | VESA 1.1 | от 640x480 до 1280x1024 при 4, 8, 15, 16-bit цветах (HiColor) |
1995 | VESA 1.2 | от 640x480 до 1600x1200 при 4, 8, 15, 16, 24-bit цветах (TrueColor) |
Однако VESA режимы после 1995 года стали одним из возможных решений для реализации режимов SVGA. Как вы уже наверное догадываетесь вторым стала Windows 95 с её концепцией драйверов. Им и будет посвящена следующая глава.
Драйверы
Итак, еще один способ работы в SVGA режиме для разработчиков игр появился с выходом Windows 95. Каким же способом ограничение преодолевалось здесь? Сразу скажу что наличие/отсутствие VESA для Windows не имело ни какого значения. Всё достаточно просто - для работы с графикой в Windows используются функции ОС, а то как её отрисовка будет выполнена в самой системе уже не ваша проблема. Таким образом в Windows программист вообще лишился возможности напрямую обращаться к видеокарте. Это проблема Windows, которая в свою очередь обращается к драйверу.
Собственно концепция драйверов, появившихся в Windows 95, не нова. Они существуют на любой серьезной многозадачной операционной системе. Драйвер это программа управляющая устройством. Драйвер находится между устройством и операционной системой и обеспечивает связь Windows с аппаратной частью видеокарты.
Драйвер обеспечивает ряд стандартных функций для доступа к аппаратной части, в то же время Windows абсолютно безразлично каким образом эта самая аппаратная часть реализована. Таким образом разработчику "железа" предоставляется значительная гибкость по сравнению с VGA и VESA, правда теперь ему также нужно писать и драйвер для своей видеокарты.
В более глобальном плане драйверы открыли дорогу для значительного расширения возможностей графики и её ускорения. Связано это было с очень высокой гибкостью связки драйвер-видеокарта, когда новые возможности сначала могли реализовываться на уровне эмуляции в драйвере, а потом переносится и в аппаратную реализацию. В первую очередь это нашло применение в так называемых Windows-акселлераторах ускорявших стандартный графический режим Windows (отрисовку окон и т.п.).
Однако первое время всё было не так радужно... Во-первых работа в графическом режиме Windows была очень медленной и реализовать что-то более динамичное чем известные "Сапер" и "Косынка" было, мягко говоря, сложновато. Связано это было в первую очередь с тем, что самый быстрый, прямой доступ к видеопамяти из Windows был невозможен. Поэтому применить наработанные в MS-DOS графические библиотеки для работы в режимах VGA и VESA было нельзя. В итоге пусть и не оптимальные в плане аппаратного ускорения игры под VGA/VESA режимы MS-DOS были быстрее чем с аппаратной акселерацией под Windows.
Принцип работы видеокарты в графическом режиме Windows с использованием драйвера:
работа в графическом режиме Windows была удобной, но очень медленной из-за участия всей "махины" Windows в каждой операции рисования и отсутствия прямого доступа к видеокарте |
Для решения этой проблемы Microsoft в срочном порядке выпускает пакет DirectX.
Интерфейсы
Однако прежде чем приступить к описанию DirectX разберемся с тем, что же такое "интерфейс". Интерфейс в самом общем смысле это некоторый стандарт по коммуникации. Он может быть как аппаратным, например шина USB, определяющим способ общения между устройствами, так и программным - определяющим способ общения между программами, а также множество других интерфейсов в числе которых и оконный интерфейс Windows (Windows GUI [Graphical User Interface - графический интерфейс пользователя]). Существуют также интерфейс прикладного программирования (Application Programming Interface - API) которые представляет собой интерфейс между программистом пишущим программу и возможностями предоставляемыми ему операционной системой. Так вот, все рассматриваемые в статье интерфейсы являются в первую очередь интерфейсами прикладного программирования. Для того чтобы тот или иной интерфейс прикладного программирования появился в системе, его функции (библиотеки подпрограмм) должны быть тем или иным способом установлены в системе - в Windows 2000 например по умолчанию уже установлены DirectX 7.0 и OpenGL. Кроме того, средства разработки программ для данной операционной системы должны быть оснашены заголовочными файлами описывающими эти функции и (опционально) дополнительными библиотеками для облегчения разработки программ. Например Microsoft регулярно выпускает свои DirectX SDK (Software Development Kit - Набор для разработки программ) для своего инструмента разработки Windows приложений - Microsoft Visual Studio. В свою очередь уже операционная система с помощью драйвера видеокарты может связать программные вызовы этих функций приложением (например игрой) с её аппаратной частью.
Схематично это можно представить следующим образом:
интерфейс прикладного программирования состоит из двух неразрывно связанных частей: программного ядра занимающего собственно выполнением функций интерфейса и средства для разработки программ способных эти функции использовать |
Интерфейс Microsoft DirectX
Идея DirectX была проста - предоставить разработчикам низкоуровневый доступ к аппаратному обеспечению (в нашем случае к видеокарте), в стиле MS-DOS, в независимом от конечного устройства виде, т.е. сохранив все преимущества "драйверного" подхода. В первую очередь DirectDraw и Direct3D (два графических интерфейса DirectX) были нацелены на достижение максимально высокой скорости работы с графикой и на обеспечение максимальной совместимости. При этом они также предоставляли массу дополнительных высокоуровневых функций облегчавших создание графики и анимации. Для обеспечения совместимости все базовые функции были продублированы программной эмуляцией, таким образом, даже если устройство не могло выполнять какую-либо функцию, она эмулировалась программно. Например я помню как играл в игру "Gorky-17" на Pentium-200MMX с S3 Trio64 V+ 1 Мб в режиме программной эмуляции Direct3D (шестой, кажется, версии). Таким образом первое время всё то дикое множество самых разнообразных карт было более-менее счесано под одну гребенку DirectX и игрописатели были более менее уверены, что их детище запустится на большинстве компьютеров.
Затем начали появляться DirectX совместимые карты. Такая карта на уровне своего драйвера поддерживала все или часть функций DirectX на аппаратном уровне, причем драйвер мог сообщать DirectX что он "умеет", а что - нет. Разработчики видеокарт сотрудничали с Microsoft предлагая включить в DirectX те или иные новые функции - таким образом DirectX потихоньку рос и расширялся. Но всё же на данный момент представляется другая, довольно строгая зависимость: то что заложено в будущую версию DirectX аппаратно реализуется в следующем поколении видеокарт. Вызвано это следующим - положим некоторая фирма реализовала новую возможность, но Microsoft отказалась включить её в DirectX - усилия пропали даром. В качестве примера можно привести печальную историю с шейдерами на GeForce2 GTS. Таким образом гораздо безопаснее сообща с Microsoft и сообществом производителей видеокарт обговорить будущие спецификации и затем приступить к их реализации. Хотя порой Microsoft считает лишним советоваться просто решая: "В будущем Windows это должно быть" и точка. Впрочем для нас это не так и плохо - это заставляет производителей суетиться - лейбл "DirectX N Compatible" в нынешнее время стоит в игровом мире очень много. В частности из-за того что программная эмуляция сейчас практически лишена смысла по двум причинам:
- скорость будет неадекватной современным потребностям;
- сейчас уже нет DirectX несовместимых карт.
Схема работы Direct3D, части DirectX интерфейса предназначенного для создания 3D графики, представлена на рисунке:
приложение использующее DirectX "общается" с любой видеокартой практически напрямую, посредством универсального Direct3D интерфейса работающего в обход большей части Windows |
Интерфейс DirectX появился вскоре после выхода Windows 95, и после этого все операционные системы начиная с Windows 95 OSR 2 несли у себя на борту ту или иную версию интерфейса DirectX. Также вместе с DirectX в Windows 95 OSR 2 появилась поддержка графического интерфейса OpenGL и это не случайно. Интерфейс DirectX принципиально состоит из двух независимых частей:
- низкоуровневой работающей с аппаратной частью;
- высокоуровневой работающей с программными вызовами.
Такая организация позволяет легко расширять вторую часть не меняя или минимально меняя первую, кроме того, первая часть может быть использования для "прикручивания" к ней других интерфейсов. Например вышеупомянутый OpenGL в Windows функционирует именно так, то есть поверх DirectX. Многие из вас должно быть помнят появившиеся именно в OSR 2 трехмерные хранители экрана написанные с использованием OpenGL.
Интерфейс 3dfx Glide
Однако наиболее популярным интерфейсом для 3D-графики, первое время, был, известный многим, Glide фирмы 3dfx. Популярность Glide была вызвана тем, что карты поддерживающие его на аппаратном уровне целиком и полностью, в отличие от DirectX и OpenGL, появились сразу же (правда это были только карты 3dfx). Популярность же самих карт была вызвана тем, что они были в общем-то первыми картами 3D-ускорителями поддерживающими не только собственный Glide, но и Direct3D с OpenGL (начиная с Voodoo2). Glide будучи разработанным для вполне специфических карт показывал на них непревзойденную скорость. Однако по мере того как количество и популярность конкурентов росли, популярность Glide падала. 3dfx отчасти погубила собственная жадность - она не стала "открывать" Glide тем самым закрыв возможность встроить поддержку Glide в карты других производителей. Когда она приняла таки решение открыть Glide было уже слишком поздно. Естественно, что производители игр не могли выпускать игру только с поддержкой Glide (хотя наличие такой поддержки долгое время было правилом хорошего тона), но как минимум с поддержкой Direct3D и/или OpenGL. Если же ресурсы команды были ограничены то игра выпускалась обычно только под Direct3D или OpenGL. В числе недостатков Glide - отсутствие программной эмуляции, хотя это скорее было запланированным ходом 3dfx чем недоработкой.
Схема работы карты в режиме Glide представлена на рисунке:
несмотря на схожесть схемы работы с Direct3D, Glide, будучи разработанным строго для определенных карт, практически совмещал интерфейс и драйвер в одном лице, то есть работа по приведению команд интерфейса к виду пригодном для аппаратной обработки была минимальной |
В системе Windows никогда не было встроенной поддержки Glide, поэтому необходимые библиотеки входили в состав дистрибутива драйвера. Расширениями Glide как и непосредственным их воплощениями в "железе" единолично занималась 3dfx.
Интерфейс OpenGL
OpenGL это промышленный стандарт интерфейса для 2D и 3D графики разработанный в начале 80-х годов фирмой Silicon Graphics. В отличие от Glide, OpenGL является открытым, так что любая фирма при желании может встроить его поддержку в свою операционную систему или видеокарту. В отличие от DirectX существующем только в мире Windows, OpenGL существует почти на всех системах, таким образом портирование (перенос) OpenGL игры на различные платформы было относительно простым. OpenGL как и DirectX предусматривал режим программной эмуляции (сколько "Quake 2" было в нем пройдено). В общем-то когда OpenGL появлялся он и был чисто программным, его основной целью было создание удобного интерфейса для создания реалистичной 2D/3D графики, а идея о его аппаратном ускорении возникла уже позже.
Принципиальных различий в принципе работу между Direct3D и OpenGL нет:
приложение использующее OpenGL "общается" с любой видеокартой практически напрямую, посредством нижнего слоя DirectX интерфейса, и работает в обход большей части Windows |
Для того чтобы обеспечить максимальную независимость от платформы, OpenGL при разработке был максимально лишен каких-бы то ни было высокоуровневых функций, он не имеет собственного формата файла, набор его примитивов весьма ограничен, сам он не умеет работать ни с одной оконной системой. Все эти недостающие компоненты необходимые для успешной разработки приложений реализуются в виде различных программных расширений и библиотек.
В отличие от DirectX где тон в плане расширения возможностей задает Microsoft и градация возможностей карт осуществляется по версии DirectX, то в OpenGL расширения добавляются по большей части разработчиками "железа" и реализуются в собственных же драйверах, а уже программист решает использовать их или нет. Причем решение это может выбираться по ходу как например сжатие текстур. Таким образом если две DirectX 8 совместимые видеокарты будут выглядеть равными для режима Direct3D, то в области расширений OpenGL эти же видеокарты могут различаться гораздо более существенно.
Поддержка OpenGL в Windows появилась вместе с выходом DirectX и присутствует в системе во всех версиях начиная с Windows 95 OSR 2.
"Итого" по интерфейсам
Может показаться невероятным, но в этоху бума 3D на ПК 1996-1997 годы, за право быть стандартным боролись до 40 (!) различных 3D интерфейсов. Победили имевшие неоспоримые преимущества. DirectX имел поддержку Microsoft, Glide имел превосходную аппаратную поддержку со стороны собственного "железа", OpenGL - признанный патриарх влияние которого на мир 3D к тому времени уже было весьма значительным. Кстати, так хорошо известные нам карты, работая на компьютерах Macintosh фирмы Apple, поддерживают совсем неизвестный нам интерфейс QuickDraw 3D. Вот она - универсальность драйверного подхода!
В общем и целом все эти три интерфейса DirectX, OpenGL и Glide преследовали одну и ту же цель создание удобного интерфейса для 2D и 3D графики. Тем не менее мы видим насколько они различны:
Интерфейс | OpenGL | DirectX | Glide |
Разработчик | Silicon Graphics | Microsoft | 3dfx |
Год появления | 1980 | 1996 | 1996 |
Открытость | Да | Да | Нет* |
Кросс-платформенность | Да | Нет | Да |
Программная | Да | Да | Нет |
Встроенные | Нет | Да | Да |
Расширяемость | Версиями интерфейса, | Версиями интерфейса | Версиями интерфейса |
* большую часть времени, когда в этом ещё был смысл |
|||
Ответим на некоторые вопросы связанные с интерфейсами.
Часто можно услышать вопрос в стиле: "А какой из интерфейсов лучше?" Ну я думаю, что сейчас вы и сами можете ответить на этот вопрос. Очевидно, что сравнивать их нельзя, потому что они не лучше и не хуже, они просто разные. У каждого из них есть свои достоинства и недостатки.
Еще один вопрос: "Может ли новая версия интерфейса влиять на скорость, если не учитывать поддержку новых аппаратных возможностей видеокарты?" Может. Ядро интерфейса это тоже программа, поэтому она может быть оптимизирована, в том числе и под новые инструкции процессора.
И снова драйверы
Вернемся к драйверам и взглянем, что же из себя представляет Windows драйвер современного 3D-ускорителя коими по праву могут считаться и все карты фирмы NVIDIA. Итак типичный драйвер состоит из четырех частей:
- собственно драйвер отвечающий за самый низкий уровень коммуникаций с видеокартой;
- драйвер для работы с интерфейсом Direct3D;
- драйвер для работы с интерфейсом OpenGL;
- всё остальное, включающее в себя всевозможные средства настройки режимов работы видеокарты.
К примеру в современных драйверах NVIDIA для Windows 2000 за эти части отвечают файлы:
- nv4_mini.sys;
- nv4_disp.dll;
- nvoglnt.dll;
- Как видно на рисунке, четвертая часть может включать в себя значительное число файлов:
С точки зрения конечного пользователя именно 4 часть представляет наибольший интерес, предоставляя доступ к всевозможным галочкам-ползуночкам-кнопочкам позволяя пользователю настроить драйвер или способ/режим функционирования видеокарты. Именно так - "или". Потому что настройки драйвера можно разделить на две принципиально разные части:
- те, что отвечают непосредственно за аппаратные возможности видеокарты, например антиалиасинг;
- те, что отвечают за функции влияющие на конечное изображение, но выполняемые на уровне драйвера.
Вторые как правило легко вычислить по запаздыванию в их появлении. Т.е. сначала возможности не было, а потом вдруг появилась почти на всех моделях видеокарт сразу. В качестве примера - технология IntelliSample, которая анализирует текстуры на уровне драйвера. Собственно говоря из-за этих возможностей драйвера вокруг них возникает столько шумихи.
Достаточно вспомнить регулярно повторяющиеся волнения касающиеся производительности драйверов. От чего же может зависеть скорость драйвера?
- Новые аппаратные возможности чипа. Очевидно что маловероятно, что драйвер задействует какую-то новую аппаратную возможность, как правило они объявляются сразу с выходом чипа. Хотя не исключен и такой вариант (в качестве примера - отключенный по умолчанию HSR во многих драйверах серии 4x.xx.). Его смысл?
- Козырь за пазухой по отношению к конкурентам;
- Аппаратная ошибка не позволявшая правильно работать была исправлена на уровне драйвера.
Однако более вероятными представляются следующие причины:
- Отключение какой-либо аппаратной возможности по причине обнаруженной в ней ошибки. При этом естественно скорость работы падает;
- Оптимизация кода драйвера, в том числе под новые процессорные инструкции - драйвер же по сути обычная программа;
- Программные оптимизации подобные IntelliSample;
- "Хитрости" - оптимизации под конкретные приложения (я думаю никого не обошел стороной скандал вокруг популярного теста 3D Mark).
Другой часто возникающий и тесно связанный с первым вопрос - почему они "глючат"? Или чаще звучащий так - почему он глючил, а новый нет? Отвечая на первый вопрос опишем возможные причины:
- Поскольку драйвер программа в ней возможны ошибки. Соответственно ответ на второй вопрос - ошибка была исправлена;
- Программа использующая драйвер написана с ошибками. Как же драйвер может это исправить? Может, если ошибка проста и понятны причины её вызывающие, драйвер может обрабатывать программу специфическим образом. Если игра популярна (а уж тем более если она часто используется в качестве теста), то производитель карты расшибется, но сделает так чтобы эта игра работала безукоризненно.
Вместо заключения
Надеюсь, что статья оказалась для вас интересной и познавательной. Однако автор статьи, в моём лице, привык нести ответственность за свои слова и поэтому считает своим долгом сделать следующее предупреждение.
Автор статьи не является программистом ни драйверов, ни приложений использующих интерфейсы Direct3D, Glide или OpenGL. Поэтому он допускает, что в статье возможны ошибки связанные с описанием принципов их работы. Однако это не значит, что вся информация бралась, что называется, "с потолка". Автор приложил все усилия, чтобы исключить подобные ситуации. Кроме того, осознавая свою степень некомпетентности, автор пытался, в общем случае, донести не столько максимально точное описание функционирования, сколько принципиальные моменты, важные для общего понимания той или иной концепции. Автор будет чрезвычайно признателен поправкам, если какие-то части статьи были изложены принципиально неверно.
Обсудить/дополнить в конференции