Готовый перевод OpenGL SuperBible (6th Edition) / OpenGL Супер Книга (6-ое издание): Введение

Глава 1 Введение
Из этой главы вы узнаете:
• Что такое графический конвейер и как OpenGL связан с ним
• Истоки OpenGL и какой он прошел путь до наших дней
• Некоторые из фундаментальных концепций, на которые мы будем опираться на протяжении всей книги

Эта книга про OpenGL. OpenGL является интерфейсом, который ваше приложение может использовать для доступа и управления графической подсистемы устройства, на котором она работает. Оно может быть чем угодно, начиная от профессиональной графической станции и заканчивая настольным компьютером, игровой консолью или даже мобильным телефоном.
Стандартизация интерфейса подсистемы увеличивает переносимость и позволяет разработчикам сконцентрироваться на создании качественных продуктов, интересного контента, а также на общей производительности их приложений, вместо того чтобы беспокоиться о специфике платформ, на которых эти приложения будут запускаться.
Эти стандартные интерфейсы называются интерфейсы прикладного программирования (или API), одним из которых является OpenGL. Эта глава знакомит вас с OpenGL, описывает, как он связан с графической подсистемой, лежащей в основе, и дает немного исторических сведений о происхождении и эволюции OpenGL.

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

Это же верно в компьютерной графике. Команды из вашей программы принимаются OpenGL и отправляются далее в графическое оборудование, которое для получения желаемого результата обрабатывает их настолько быстро и эффективно, насколько это возможно. В оборудовании в очереди на выполнение может находится очень много команд, а некоторые могут быть даже частично завершены.
Это позволяет “распараллелить” их выполнение, таким образом, что поздний этап одной команды может выполняться одновременно с более ранней стадией другой команды. Более того, компьютерная графика, в основном, состоит из множества повторений и очень схожих задач (таких как, вычисление цвета пикселя), и эти задачи, как правило, независимы друг от друга - то есть, результат закрашивания одного пикселя не зависит от другого. Так же, как автомобильный завод может строить много автомобилей одновременно, OpenGL может поделить работу, которую вы ей поручаете, и работать над ее основными элементами параллельно. Именно благодаря сочетанию конвейерной и параллельной обработки становится доступна невероятная мощь современных графических процессоров.

Цель OpenGL – создать слой абстракции между приложением и лежащей в основе графической подсистемой, часто образованной аппаратным ускорителем с одним или несколькими специализированными, высокопроизводительными процессорами, выделенной памятью и интерфейсом для дисплеев. Этот слой абстракции позволяет вашему приложению не знать, кто сделал графический процессор (graphics processing unit, GPU), как он работает или насколько хорошо он выполняет свою работу. Конечно, эту информацию можно узнать, но дело в том, что приложению это не нужно.

OpenGL спроектирован так, что должен балансировать между слишком высоким и слишком низким уровнями абстракции. С одной стороны, он призван скрыть различия между продуктами разных производителей (или различными продуктами одного производителя) и специфичными чертами систем, такими как разрешение экрана, архитектура процессора, установленная операционная система и так далее. С другой стороны, уровень абстракции должен быть достаточно низкий, чтобы программисты могли получить доступ к оборудованию и наилучшим образом использовать его. Если бы OpenGL был излишне высокоуровневым, то было бы легко создавать программы, соответствующие модели, но очень трудно использовать расширенные возможности графического оборудования, которые не были реализованы в библиотеке. Именно этой модели взаимодействия соответствует такое программное обеспечение, как игровой движок – новые возможности графического оборудования обычно требуют довольно больших изменений в игровом движке, чтобы игры, созданные с его помощью, получили к ним доступ. Если бы уровень абстракций был слишком низок, приложению нужно было бы беспокоится об архитектурных особенностях системы, на которой оно будет запускаться. Низкий уровень абстракции распространён, например, на игровых консолях, но не подходит для графической библиотеки, которая охватывает все устройства, начиная от мобильных телефонов и заканчивая мощными профессиональными графическими станциями.

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

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


Современные графические процессоры состоят из большого количества программируемых процессоров, так называемых шейдерных ядер, которые запускаю мини-программы под названием шейдеры. Каждое с относительно низкой пропускной способность ядро, обрабатывает одну команду шейдера за один и более тактов и обычно не имеет дополнительных функций, типа внеочередного исполнения (out-of-order execution), предсказания переходов (branch prediction), суперскалярной архитектуры и так далее. Однако, каждый GPU может содержать от нескольких десятков до нескольких тысяч таких ядер, и вместе они могут выполнить огромный объем работы. Графическая система разбита на ряд этапов, каждый из которых представлен либо шейдером, либо фиксированным, а возможно настраиваемым блоком обработки.

Рисунок 1.1: Упрощённый графический конвейер

На рисунке 1.1, в рамках с закругленными углами показаны fixed-function этапы графического конвейера, в рамках с квадратными углами - программируемые (они выполняют шейдеры, которые вы им передаете). На практике, некоторые или все fixed-function этапы, на самом деле, могут быть реализованы и в шейдерном коде - вам просто не нужно писать его самостоятельно, сам производитель GPU, как правило, поставляет его в качестве части драйвера, прошивки или другого системного ПО.

Истоки OpenGL и его эволюция
Своими корнями OpenGL уходит в компанию Silicon Graphics, Inc. (SGI) и их разработку - IRIS GL. GL означал (и до сих пор означает) “Graphics Library” (графическая библиотека, прим. перев.) и в большей части современной документации по OpenGL вы увидите термин "the GL", что означает "the graphics library", родом из той эпохи. Silicon Graphics была [1] производителем графических станций high-end класса. Они были чрезвычайно дороги, и с помощью собственной API для графики не помогала.Другие компании производили гораздо более недорогие решения, работавшие на конкурирующих API, которые часто были совместимы между собой. В начале девяностых, SGI понял, что переносимость является важным требованием и поэтому решили очистить IRIS GL, удалив системно-зависимые части API и выпустив в качестве открытого стандарта, который может быть реализован бесплатно кем угодно. Самая первая версия OpenGL была выпущена в июле 1992 и имела версию OpenGL 1.0.
----------------------------------------------------------
1. Silicon Graphics, или, точнее, SGI, существует до сих пор, но обанкротилась в 2009 году, и со всеми активами и брендами бала приобретена компанией Rackable Systems, которая сама теперь стала зваться SGI, но не стала работать на рынке high-end графики.

В том же году, SGI также сыграл важную роль в создании наблюдательного совета за архитектурой OpenGL - OpenGL Architectural Review Board (ARB), первоначальный состав которого включал такие компании, как Compaq, DEC, IBM, Intel, and Microsoft. Вскоре другие компании, такие как Hewlett Packard, Sun Microsystems, Evans & Sutherland и Intergraph присоединились к этой группе. OpenGL ARB - это орган по стандартизации, который разрабатывает, управляет и составляет спецификацию OpenGL и в настоящее время является частью Khronos Group, более крупного консорциума компаний, курирующих разработку многих открытых стандартов. Некоторые из первоначальных членов организации либо более не существуют (ушли из бизнеса, были приобретены или объединены с другими компаниями) , либо не являются членами ARB, после того, как отказались от бизнеса в сфере графики. Тем не менее, некоторые все еще существуют либо под новыми именами, либо как организации, которые были вовлечены в развитие самой первой версии OpenGL более 20 лет назад.

На момент написания, было 17 редакций спецификации OpenGL. Номера версий и даты публикаций приведены в таблице 1.1. Эта книга описывает версию 4.3 спецификации OpenGL.

Таблица 1.1 Версии OpenGL и дата публикации[2].
----------------------------
2. Да, две версии в одно время!

Основной профиль OpenGL
Двадцать лет - долгое время в развитии передовых технологий. В 1992 году флагманом среди процессоров Intel был 80486, математические сопроцессоры не являлись обязательным архитектурным компонентам, а Pentium еще не успели изобрести (или по крайней мере выпустить). Apple в своих компьютеры по-прежнему использовала устаревшие процессоры Motorola 68K, а процессоры PowerPC, на который они впоследствии перешли, появятся только во второй половине 1992. Высокопроизводительное графическое ускорение было чем-то, что не было особенно распространено в домашних компьютерах. Если вы не имели доступ к высокопроизводительной графической станции, вам, вероятно, не стоило надеяться использовать OpenGL. Программный рендеринг правил миром, и демосцена Unreal от Future Crew выиграла Assembly ’92. Лучшее, на что вы могли надеяться на домашнем компьютере - простой рендеринг закрашенных многоугольников или спрайтов. Уровень 3D-графики на домашнем компьютере 1992 года показан на рисунке 1.2.

Рисунок 1.2: демосцена Unreal от Future Crew (1992 год)

Со временем, цены на графическое оборудование упали, производительность выросла, и, частично ввиду низкой стоимости карт расширения для ПК и частично в связи с увеличением производительности игровых консолей, поддержка новых функций и возможностей, появившихся в доступных графических процессорах, была добавлена в OpenGL. Большинство этих функций возникло в расширениях, предложенных членами OpenGL ARB. Некоторые взаимодействовали хорошо друг с другом и с существующими функциями в OpenGL, а некоторые нет. Кроме того, как только изобретали новые, более эффективные способы выжимать производительность из графических систем, их просто добавляли в OpenGL, в результате чего он мог делать одни и те же вещи разными способами.

На протяжении многих лет ARB занимала строгую позицию относительно обратной совместимости, впрочем, как и сегодня. Однако, за обратную совместимость приходится платить большой ценой. Изменились подходы - что могло хорошо работать или, по крайней мере, не создавать серьёзных проблем на графическом оборудовании середины 1990-ых, не очень хорошо (удовлетворяет / соответствует) архитектуре современных графических процессоров. Определить, как новые возможности будут взаимодействуют со старыми унаследованными, не так легко, что, во многих случаях, делает невозможным просто добавить их в OpenGL. Реализация OpenGL стала столь сложной задачей, что драйверы, как правило, имели больше ошибок, чем следовало, а производителям графического оборудования нужно было прикладывать много усилий, чтобы сохранять поддержку всех унаследственных возможностей, которые не способствовали ни развитию, ни инновациям в графике.


По этим причинам, в 2008 году ARB решила сделать "ответвление" OpenGL спецификации на два профиля. Первый - основной и современный профиль, из которого убрали целый ряд унаследованных возможностей, оставив только те, которые имеют аппаратное ускорение на современном графическом оборудовании. Эта версия спецификации на несколько сотен страниц короче[3], чем другая - профиль совместимости. Профиль совместимости поддерживает обратную совместимость со всеми версиями OpenGL начиная с версии 1.0. Это означает, что написанное в 1992 году программное обеспечение должно компилироваться и запускаться на современных видеокартах с увеличенной более чем в тысячу раз производительностью, чем во времена, когда эта программа была сделана впервые.

Профиль совместимости существует, чтобы позволить разработчикам программного обеспечения поддерживать устаревшие приложения и добавлять новые функции без необходимости выкидывать годы работы только для того, чтобы перейти на новый API. Однако, большинство экспертов OpenGL настоятельно рекомендуют использовать для разработки новых приложений основной ​​профиль. В частности, на некоторых платформах, новые возможности доступны только при использовании основного профиля OpenGL, а на других, приложение, написанное с использованием основного профиля OpenGL, будет работать быстрее, чем то же не модифицированное, кроме запроса профиля совместимости, даже если он использует только функции, которые доступны в основном профиле OpenGL. Наконец, если функция находится в профиле совместимости и была удалена из основного, то, весьма вероятно, на то были веские причины, и это знак того, что вы не должны её использовать. Эта книга охватывает только основной профиль OpenGL, и это последний раз, когда мы упомянули профиль совместимости.
---------------------------------------
3. Спецификация основного профиля все еще довольно-таки толстая, в ней свыше 700 страниц.

Примитивы, конвейеры и пиксели

Как уже обсуждалось, модель, используемая OpenGL, схожа с производственной линией, или конвейером. Поток данных в этой модели, как правило, имеет только одно направление: данные формируются командами, которые вызываются вашей программой, входят в начало конвейера и проходят от одного этапа к другому, пока не достигнут конца конвейера. По пути, шейдеры или fixed-function блоки в конвейере могут брать данные из буферов или текстур, которые являются структурами, спроектироваными для хранения информации, используемой при рендеринге. Некоторые этапы в конвейере могут даже хранить информацию в этих буферах или текстурах, позволяя приложению читать или сохранять данные, или даже производить обратную связь.

Фундаментальная единица рендера в OpenGL известна как примитив. OpenGL поддерживает много видов примитивов, но только три основных типа примитивов, которые можно рендерить: точки, линии, треугольники. Всё, что вы видите нарисованным на экране - это группа (возможно, хитро окрашенных) точек, линий и треугольников. Приложение, как правило, разбивает сложные поверхности на очень большое количество треугольников и отправляет их в OpenGL, где они отрисовываются с помощью аппаратного ускорителя, называемого растеризатором. Треугольники относительно легко нарисовать. Как полигоны, треугольники всегда выпуклые, и поэтому легко разработать правила их заполнения. Так как выпуклые полигоны всегда можно разбить на два и более треугольника, оборудование изначально поддерживает рендер треугольников и полагается на другие подсистемы[4], чтобы разбить сложную геометрию на треугольники. Растеризатор является отдельным аппаратным блоком, который преобразует трехмерное представление треугольника в серию пикселей, которые должны быть нарисованы на экране.

Точки, линии и треугольники формируются из набора одного, двух или трех вершин, соответственно. Вершина просто точка в пространстве координат. в нашем случае, мы полагаем в трёхмерной координатной системе. Графический конвейер делится на две главные части. Первая часть, больше известная front-end, обрабатывает вершины и примитивы, в конечном счёте формируя из них точки, линии и треугольники, которые будут переданы в растеризатор. Это называется сборкой примитивов (primitive assembly). Далее растеризатор из, по сути, векторного представления преобразует геометрию во множество независимых пикселей. Затем они передаются в back-end часть, которая осуществляет проверку на глубину (depth test), стенсил тест (stencil test), фрагментное затенение (fragment shading), смешивание (blending) и обновление выходного изображения.

По мере прочтения книги, вы поймете, как приказать OpenGL работать на вас. Далее, мы узнаем как создавать буферы и текстуры, и как их добавить в вашу программу. Мы также посмотрим, как писать шейдеры для обработки данных, и как настроить fixed-function блоки OpenGL, чтобы реализовать то, что вы хотите. OpenGL - это действительно большое собрание простых понятий, построенных друг на друге. Иметь хорошую базу и общую картину системы необходимо, и в следующих главах мы надеемся вас этим обеспечить.
------------------------------
4. Иногда, эти подсистемы являются аппаратными модулями, а иногда функциями драйверов в программной обеспечении.

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

Переведено на Нотабеноиде
http://notabenoid.org/book/54048/234473

Переводчики: vk955