В чем разница между opengl и opencl - разница между

Структура API OpenGL

API OpenGL описан на языке C без применения C++ ради простоты и платформонезависимости. Он состоит только из функций, констант и примитивных типов, объявленных через , таких как .

Функции делятся на две группы:

команды (англ. commands) для изменения состояния драйвера
запросы (англ. queries) состояния драйвера

Вот несколько примеров:

функция-команда устанавливает цвет очистки; RGBA компоненты цвета передаются как число с плавающей точкой на отрезке .
функция-команда очищает буфер кадра путём заливки пикселей цветом очистки.
функция-запрос возвращает строковое значение некоторой константы или величины в видеодрайвере, выбор величины зависит от параметра ; при этом можно преобразовать в с помощью .
тип данных означает “число с плавающей точкой на отрезке ”; при этом никаких проверок принадлежности диапазону компилятор делать не будет, потому что тип объявлен просто как .

Функции-команды ничего не возвращают, даже статуса своего выполнения. Это даёт возможность выполнить команду асинхронно, не заставляя приложение ждать, пока видеодрайвер отправит данные на видеокарту и получит от неё ответ.

История

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

К началу 1990-х годов Silicon Graphics (SGI) была лидером в области трехмерной графики для рабочих станций. Их API IRIS GL стал отраслевым стандартом, более широко используемым, чем основанный на открытых стандартах PHIGS . Это было связано с тем, что IRIS GL считался более простым в использовании и поддерживал рендеринг в немедленном режиме . Напротив, PHIGS считался сложным в использовании и устаревшим по функциональности.

Конкуренты SGI (включая Sun Microsystems , Hewlett-Packard и IBM ) также смогли вывести на рынок 3D-оборудование, поддерживаемое расширениями, сделанными для стандарта PHIGS, что вынудило SGI открыть исходный код версии IrisGL в качестве общедоступного стандарта под названием OpenGL .

Однако у SGI было много клиентов, для которых переход с IrisGL на OpenGL потребовал значительных инвестиций. Более того, в IrisGL были функции API, которые не имели отношения к трехмерной графике. Например, он включал API-интерфейс управления окнами, клавиатуры и мыши, отчасти потому, что он был разработан до X Window System и Sun NeWS . К тому же библиотеки IrisGL были непригодны для открытия из-за проблем с лицензированием и патентами. Эти факторы потребовали от SGI продолжать поддерживать расширенные и проприетарные программные API-интерфейсы Iris Inventor и Iris Performer, в то время как рыночная поддержка OpenGL становилась все более зрелой.

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

В 1992 году SGI возглавила создание Совета по обзору архитектуры OpenGL (OpenGL ARB), группы компаний, которая будет поддерживать и расширять спецификацию OpenGL в будущем.

В 1994 году SGI обдумывала идею выпустить нечто под названием « OpenGL ++ », которое включало бы такие элементы, как API графа сцены (предположительно основанный на их технологии Performer ). Спецификация была распространена среди нескольких заинтересованных сторон, но так и не превратилась в продукт.

Microsoft выпустила Direct3D в 1995 году, который со временем стал основным конкурентом OpenGL. Более 50 разработчиков игр подписали открытое письмо в Microsoft, выпущенное 12 июня 1997 года, с призывом к компании активно поддерживать Open GL. 17 декабря 1997 года Microsoft и SGI инициировали проект Fahrenheit , который был совместным усилием с целью унификации интерфейсов OpenGL и Direct3D (а также добавления API графа сцены). В 1998 году к проекту присоединилась Hewlett-Packard. Первоначально он обещал упорядочить мир интерактивных API-интерфейсов трехмерной компьютерной графики, но из-за финансовых ограничений SGI, стратегических соображений Microsoft и общего отсутствия поддержки со стороны отрасли в 1999 году от него отказались.

В июле 2006 года Совет по обзору архитектуры OpenGL проголосовал за передачу контроля над стандартом API OpenGL группе Khronos.

Вычисления — это отрисовка

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

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

Задача

Попробуем решить следующую задачу. Пусть дана матрица размером H×W = 64×64. Выделим под неё память и заполним
суммами номеров строк и столбцов. Работать будем с однобайтовыми числами, так что от сумм будем
брать только младший байт. Заодно выделим память для результата.

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

Данные будут однобайтовыми, но вспомним, что в текстуре каждый пиксель имеет формат . Процессоры
архитектуры хранят целые числа в формате
little-endian,
поэтому если рассматривать эти
четыре байта как одно 4-байтовое число, то младшим байтом будет . Там и будем хранить наше значение.

Я буду писать на C++, но этот код будет легко портировать на C, заменив на ,
на , а на .

Здесь используется тип из , чтобы гарантировать, что элементы будут 32-битные, то есть 4-байтовые.
Фактически, это псевдоним для .

И сразу выведем младшие байты элементов массива на экран. Чтобы не загромождать терминал
выведем только верхний левый угол 8×8.

(Полный исходный код со всеми заголовочными файлами будет приведён в конце.)

В результате на экране появится следующее:

Создание контекста

Команды OpenGL, как уже было сказано, абстрактны и не привязаны к какому-то конкретному устройству.
Поэтому, чтобы они отправлялись на GPU, нужно создать контекст. Если мы пользуемся, например,
библиотекой GLUT, то она делает это за нас. Но она привязывает его к окну, а мы хотим создать
безоконное приложение.

Для создания безоконного контекста (offscreen context) можно воспользоваться библиотекой EGL,
которая для этого и предназначена.

Информация о дисплее, контексте и поверхности, на которой будет происходить отрисовка
будет храниться в следующих основных переменных.

Сперва получим информацию о текущем дисплее. На нём мы рисовать не будем, но это
нужно для создания контекста.

Инициализируем EGL.

Теперь создадим конфигурацию поверхности на которой будем рисовать. Это будет не
окно, а пиксельный буфер (pbuffer) в памяти. Укажем также глубину цвета и версию
OpenGL.

Нам также потребуются две вспомогательные переменные для хранения конфигурации.

Конфигурация задаётся в виде массива пар параметр — значение. Признак конца
конфигурации — .

Параметр очень важен! Если указать что-то кроме ,
то OpenGL ES 2.0 не будет работать как нужно.

Следующий шаг — создание поверхности на основе нашей конфигурации. Отображать на ней мы всё равно ничего не будем,
поэтому можно задать размеры равными 1×1.

Делаем OpenGL текущим API.

Наконец, создаём контекст и делаем его активным для текущего потока.

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

В конце программы, когда контекст не нужен, удаляем его.

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

Создание фреймбуфера

Раз мы не будем выводить изображение на экран, нам потребуется новый фреймбуфер (FBO, famebuffer object),
в который и будут записываться результаты. У каждого фреймбуфера есть уникальный номер,
который назначается ему при создании. Будем хранить его в переменной .

Параметр 1 во второй строке означает, что мы создаём один фреймбуфер. Команда
сразу после создания привязывает его (bind), то есть делает его текущим.

Фрагментный шейдер

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

Нужно заметить, что значения цветовых компонент передаются в вещественном формате. То есть диапазон
0..255 отображается на 0.0..1.0. При записи результата во фреймбуфер происходит обратное преобразование.

Также мы будем передавать из программы uniform-переменную , содержащую коэффициент, на который
мы и будем умножать младший байт (напомню, это компонента R). Если мы хотим удваивать элементы, то
надо будет в программе задать и запустить вычисления.

Рассмотрим код шейдера.

Здесь задана средняя точность для всех вещественных переменных.

Сэмплер, связанный с нашей текстурой я назвал , хотя можно было назвать как угодно. Также здесь
снова объявлена varying-переменная . И, наконец, задан параметр . Значения всем uniform-переменным,
как уже было сказано, будут присвоены в самой программе. В шейдере же мы считаем их известными.

Сам шейдер тоже предельно прост. В первой строке функции с помощью встроенной функции
мы извлекаем цвет соответствующего текселя. Во второй, умножаем младший байт (R) на a, остальные (G, B, A) оставляем
неизменными.

Здесь нет , цвет фрагмента возвращается через встроенную переменную .

Код для вставки в программу.

Абстрактные различия между OpenGL и GLES2[править]

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

GLSL отличаются
GLES2 требует точности,это не совместимо с OpenGL 2.1.

нуждаются в указании самыми первыми строками в некоторых GLSL компиляторах (например, на PowerVR SGX540), поэтому мы не можем использовать директивы.
Вместо этого, мы будем писать первыми строками C++ код связанный с версиями:

constGLchar*sources2={
#ifdef GL_ES_VERSION_2_0
"#version 100\n"
// Note: OpenGL ES automatically defines this:
// #define GL_ES
#else
"#version 120\n",
#endif
source};
glShaderSource(res,2,sources,NULL);

Так как мы используем одну и ту же версию GLSL во всех наших учебных пособиях, это наиболее простое решение.
Мы охватим и прочие уточнения в следующем разделе.

Доступность

Разработка приложений Direct3D нацелена на платформу Microsoft Windows .

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

С точки зрения разработчика приложений Direct3D и OpenGL одинаково открыты; полная документация и необходимые инструменты разработки доступны без ограничений.

API	Поддержка рабочего стола	Встроенная поддержка системы	Лицензия
Direct3D	Microsoft Windows , Xbox	Windows Embedded , Windows CE (через Direct3D Mobile )	Проприетарный
OpenGL	Кроссплатформенность	Кроссплатформенность через OpenGL ES	Открытый стандарт, некоторые функции запатентованы

Более подробно, это два API компьютерной графики:

Direct3D — это проприетарный API от Microsoft, который предоставляет функции для рендеринга двухмерной (2D) и трехмерной (3D) графики и использует аппаратное ускорение, если оно доступно на видеокарте. Он был разработан корпорацией Microsoft для использования на платформе Windows .
OpenGL — это открытый стандартный API, который предоставляет множество функций для рендеринга 2D- и 3D-графики и доступен в большинстве современных операционных систем, включая , помимо прочего, Windows , macOS и Linux .

Обратите внимание, что многие важные расширения и методы OpenGL , хотя и задокументированы, также запатентованы, что создает серьезные юридические проблемы для их реализации (см. Проблемы с Mesa ).. И OpenGL, и Direct3D реализованы в драйвере устройства отображения

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

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

Ссылки [ править ]

^ http://blogs.msdn.com/b/windows-embedded/archive/2009/06/25/component-tales-directx.aspx
^ a b «Лицензия Microsoft DirectX» . legal.ubi.com . Проверено 21 июля 2015 .
^ а б http://www.opengl.org/about/
^ https://www.khronos.org/opengles/
^
^ «Начало работы с Direct3D — разработка приложений для Windows» . msdn.microsoft.com . Проверено 21 июля 2015 .
^ «Логотипы, товарные знаки и правила Khronos» . Хронос Групп . Хронос Групп. Июнь 2016 . Проверено 25 июля +2016 .
^ Группа, Хронос. «Обзор OpenGL» . www.opengl.org . Проверено 21 июля 2015 .
^ idr: OpenGL 3 и Mesa: X.Org Wiki — События / XDC2009 / Примечания . Проверено 28 октября 2011 года.
^ Windows Vista и OpenGL-Факты , Информационный бюллетень OpenGL Pipeline, Том 003, 20 апреля 2007 г.
^ «Архивная копия» . Архивировано из оригинала на 2011-09-13 . Проверено 4 сентября 2011 .
^ «УГОЛ: Почти нативный графический слой» . code.google.com . Проверено 21 июля 2015 .
^ «План Джона Кармака 12/23/96» . 23 декабря 1996 г.
^ a b «Открытое письмо в Microsoft» Криса Хеккера, выпуск журнала Game Developer Magazine, апрель – май 1997 г.
^ Khronos Group — OpenGL — языковые привязки
^ Спинеллис, Diomidis (2006). Качество кода: перспектива открытого исходного кода . Эддисон Уэсли. С. 182–183. ISBN 0-321-16607-8.
^ Что лучше: использовать один вызов DrawPrimitive или несколько? Архивировано 6 сентября 2006 года на Wayback Machine Nexe.
^ Графические API в Windows Vista
^ DirectX 12
^ https://www.khronos.org/assets/uploads/developers/library/2014-gdc/Khronos-OpenGL-Efficiency-GDC-Mar14.pdf Эффективность OpenGL: AZDO
^ http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead
^ http://blogs.msdn.com/b/chuckw/archive/2012/06/20/direct3d-feature-levels.aspx
^ Direct3D Mobile , Microsoft, 6 января 2010 г.
^ Поддержка шейдерных моделей для Windows Phone 8.

OpenGL ES в деталях

OpenGL ES — это облегченный низкоуровневый API, основанный на широко распространенной библиотеке OpenGL.
OpenGL ES выступает посредником между приложением и аппаратным или программным графическим движком.

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

Достоинства API

Широко распространенный, относительно открытый стандарт
Любой желающий может скачать OpenGL ES спецификацию и свободно использовать ее в своих продуктах. В настоящее время OpenGL единственный независимый графический стандарт, получивший признание и поддержку производителей различных устройств.
Компактность и экономичность
OpenGL ES занимает мало места и требует для работы минимум оперативной памяти. Оптимизирован поток команд/данных. Все это позволяет получать на выходе компактный и эффективный программный код.
Незаметное переключение с аппаратного на программный рендеринг
Хотя OpenGL ES и предназначен для работы с аппаратными ускорителями графики, он может в случае необходимости реализовать запросы в виде подпрограмм, выполняемых непосредственно процессором устройства. Поэтому, если даже сейчас устройство не поддерживает аппаратно какой-нибудь OpenGL запрос, возможно в будущих моделях он будет реализован и Вам не потребуется заново переписывать программу.
Расширяемая архитектура
Новые аппаратные возможности могут быль легко интегрированы в систему с помощью механизма расширений (OpenGL extension). По мере того, как расширение становится широко распространенным, оно включается в ядро OpenGL ES.
Простота использования
Как и OpenGL, OpenGL ES хорошо структурирован и интуитивно понятен.
Нет проблем с документацией

В сети существует огромное количество документации по OpenGL. Работа с OpenGL ES практически не отличается от работы с простым OpenGL

Расширения [ править ]

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

С другой стороны, Direct3D указан только одним поставщиком ( Microsoft ), что приводит к более согласованному API, но запрещает доступ к функциям конкретного поставщика. Например, технология NVIDIA UltraShadow недоступна в стандартных API Direct3D на момент написания. [ необходима цитата ] [ когда? ] Direct3D поддерживает расширения формата текстур (через FourCC ). Когда-то они были малоизвестны и редко использовались, но теперь используются для сжатия текстур S3 .

Когда видеокарты добавили поддержку пиксельных шейдеров (известных в OpenGL как «фрагментные шейдеры»), Direct3D предоставил один стандарт «Pixel Shader 1.1» (PS1.1), с которым GeForce 3 и выше и Radeon 8500 и выше заявляли о совместимости. В OpenGL к тем же функциям можно было получить доступ через множество настраиваемых расширений.

Теоретически подход Microsoft позволяет использовать один путь кода для поддержки карт обеих марок, тогда как в OpenGL программисты должны писать две отдельные системы. [ требуется пояснение ] В действительности, однако, из-за ограничений на обработку пикселей этих ранних карт, Pixel Shader 1.1 был не чем иным, как версией специфичных для NVIDIA расширений OpenGL на языке псевдо-ассемблера. По большей части, единственные карты, заявляющие о функциональности PS 1.1, были от NVIDIA, и это потому, что они изначально были созданы для нее. Когда была выпущена Radeon 8500, Microsoft выпустила обновление для Direct3D, которое включало Pixel Shader 1.4, который был не чем иным, как версией ATI на языке псевдо-ассемблера.-специфические расширения OpenGL. Единственными картами, которые заявили о поддержке PS 1.4, были карты ATI, потому что они были разработаны с точным оборудованием, необходимым для реализации этой функциональности.

Такая ситуация просуществовала недолго в обоих API. Карты затенения пикселей второго поколения функционировали гораздо более похоже, каждая архитектура развивалась в сторону одного и того же типа обработки пикселей. Таким образом, Pixel Shader 2.0 допускает унифицированный путь кода в Direct3D. Примерно в то же время OpenGL представила свои собственные расширения вершинных и пиксельных шейдеров, одобренные ARB ( и ), и оба набора карт также поддерживали этот стандарт.

Получение информации о версии OpenGL

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

Для получения информации мы применим функцию-запрос с тремя различными параметрами. На эту тему есть статья Get Context Info (opengl.org).

константа с именем GL_VERSION возвращает строку версии OpenGL, причём в начале строки обязательно стоит , а остальная часть строки не определена. Например, строка обозрачает “OpenGL версии 3.0, реализуемый подсистемой графики Mesa версии 10.3.2”.
константа с именем GL_VENDOR возвращает имя поставщика реализации OpenGL. Например, строка обозначает “Видеодрайвер предоставлен OpenSource-подразделением корпорации Intel”.
константа с именем GL_EXTENSIONS содержит полный список расширений, разделённый пробелами. Список обычно насчитывает свыше ста расширений.

Что такое OpenCL

Гетерогенная система — это система, которая использует больше процессоров или ядер для повышения производительности. Процессоры могут быть похожими или разными в зависимости от задачи. OpenCL — это фреймворк, который помогает писать программы для разнородных систем. Таким образом, программист может использовать OpenCL для написания программ для систем с несколькими ЦП, графическими процессорами, процессорами цифровых сигналов (DSP), полевыми программируемыми массивами шлюзов (FPGA) и т. Д. Кроме того, он позволяет выполнять параллельные вычисления с использованием параллелизма на основе задач и данных.

Ядро — это функция, которая выполняется на устройстве OpenCL. OpenCL определяет интерфейс прикладного программирования (API), позволяющий программам, запущенным на хосте, запускать ядра на вычислительных устройствах и управлять памятью устройства. Кроме того, он предоставляет язык, похожий на C, для написания программ. Он имеет API для C, C ++ и других языков и технологий, таких как Python, Java, Perl, NET и т. Д.

Переносимость [ править ]

Запатентованный Direct3D официально реализован только на семьях Windows от Microsoft операционных систем, в том числе встроенных версий , используемых в Xbox семействе игровых консолей и Sega «s Dreamcast . Несколько в основном функциональных переопределений Direct3D API были сделаны третьими сторонами, такими как Wine , проект по переносу общих Windows API на Unix-подобные операционные системы, и Cedega , проприетарный форк Wine. Однако этот процесс все больше затрудняется из-за взаимозависимости DirectX от многих других проприетарных компонентов Windows, а также из-за того, что проприетарный характер Direct3D требует сложного процессаобратная инженерия .

OpenGL имеет реализации, доступные на многих платформах, включая Microsoft Windows, системы на основе Unix, такие как Mac OS X , Linux . Nintendo и Sony разработали свои собственные библиотеки, которые похожи, но не идентичны OpenGL. [ необходима цитата ] Подмножество OpenGL было выбрано в качестве основной графической библиотеки для Android , BlackBerry , iOS и Symbian в форме OpenGL ES .

Драйвер Microsoft OpenGL обеспечивает аппаратное ускорение в Windows Vista; поддержка была прекращена в Windows XP [ необходима цитата ] вскоре после того, как они не смогли предоставить низкоуровневую поддержку графического API Fahrenheit для слияния OpenGL и Direct3D в конце 1990-х. Аппаратное ускорение OpenGL в Windows достигается за счет того, что пользователи сначала устанавливают устанавливаемые клиентские драйверы (ICD), разработанные производителями графических процессоров . Эти ICD практически во всех случаях поставляются в комплекте со стандартным пакетом загрузки драйверов от поставщика оборудования (IHV), поэтому установки последних графических драйверов достаточно для обеспечения аппаратной поддержки OpenGL.

Совсем недавно проект Google почти Native Graphics Layer Engine ( ANGLE ) предоставляет средства для преобразования вызовов приложений OpenGL ES 2.0 в DirectX 9 . Это сделано для того, чтобы WebGL (вариант подмножества OpenGL для Интернета) мог работать в общей среде выполнения Direct3D, что означает меньшую вариативность между поставщиками.

Структура [ править ]

OpenGL, первоначально разработанный для тогда еще мощных рабочих станций SGI, включает в себя множество функций, таких как стерео- рендеринг и подмножество изображений , которые обычно считались ограниченными для использования в играх, хотя стереоскопические игры вызвали больший интерес с развитием 3D-дисплеев потребительского уровня. API в целом содержит около 250 вызовов, но только подмножество, возможно, из 100, полезно для разработки игр. [ необходима цитата ] Тем не менее, никакого официального подмножества, специфичного для игр, так и не было определено. MiniGL, выпущенный 3Dfx в качестве временной меры для поддержки GLQuake , мог бы послужить отправной точкой, но дополнительные функции, такие как трафаретвскоре были приняты играми, и продолжалась поддержка полного стандарта OpenGL. Сегодня рабочие станции и потребительские машины используют одни и те же архитектуры и операционные системы, поэтому современные версии стандарта OpenGL все еще включают эти функции, хотя только специальные видеокарты класса рабочих станций ускоряют их.

Требования

Соблюдайте все требования к системе для создания приложения OpenGL ES для iOS и Android. Установите рабочую нагрузку разработки мобильных приложений на языке C++ в Visual Studio Installer, если еще не сделали этого. Для получения шаблонов OpenGL ES, а также для создания приложения для iOS, включите дополнительные инструменты разработки C++ для iOS. Чтобы выполнить сборку для Android, установите средства разработки C++ для Android и необходимые сторонние инструменты: Android NDK, Apache Ant и Google Android Emulator.

Для повышения производительности эмулятора на платформах Intel один из вариантов — установить Intel Hardware Accelerated Execution Manager (HAXM). Подробные инструкции см. в статье Установка кросс-платформенной разработки мобильных приложений на C++.

Для сборки и тестирования приложения iOS потребуется компьютер Mac. Настройте его в соответствии с инструкциями по установке. Дополнительные сведения о настройке компьютера для разработки приложений iOS см. в разделе Установка и настройка средств для разработки с помощью iOS.

Дальнейшее чтение [ править ]

Гинзбург, Дэн; Пурномо, Будириджанто; Шрейнер, Дэйв; Мунши, Афтаб (2014). Руководство по программированию OpenGL ES 3.0 . Эддисон-Уэсли Профессионал. ISBN 978-0-321-93388-1.
Пулли, Кари; Аарнио, Томи; Миеттинен, Вилле; Роймела, Киммо и Ваарала, Яни (2007). Мобильная 3D-графика с OpenGL ES и M3G . Морган Кауфманн. ISBN 978-0-12-373727-4.
Астл, Дэйв и Дурнил, Дэвид (2004). OpenGL ES Разработка игр . Курс Технологии PTR. ISBN 1-59200-370-2.
Пулли, Кари; Аарнио, Томи; Роймела, Киммо и Ваарала, Яни. Разработка интерфейсов графического программирования для мобильных устройств . IEEE CG&A 2005 . DOI : 10,1109 / MCG.2005.129 .

Расширения OpenGL

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

В UNIX-системах и на мобильных устройствах доступны достаточно свежие версии OpenGL (обычно 3.0 и выше), где многие важные расширения уже стали частью ядра стандарта.
В Windows версии старше OpenGL 1.1 напрямую недоступны, но разработчики драйверов дают доступ к ним через механизм расширений. Если видеодрайвер не установлен, будет доступен только OpenGL 1.1, обладающий весьма ограниченными возможностями.

Функция, описанная в расширении, может не существовать в конкретной реализации OpenGL (если она не поддерживает данное расширение). Поэтому программист должен

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

В стандарте OpenGL не описан способ получения адреса, и каждая операционная система или мультимедийная библиотека предоставляет свой способ. В SDL2 есть функция , которая по имени OpenGL-функции возвращает её адрес или , если функция недоступна.