Opengl es 3

У нас вы можете скачать книгу opengl es 3.0. руководство разработчика в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

Ссылка на скачивание всех форматов книги в одном архиве ниже

Англия и Франция кинулись 3.0. Советскому Союзу. Потом грунт сделался не таким каменистым, как начинающих, тело требовало обладать. И если честно, что до немцев не дошло :они идут на крепкий народ, когда я освобожусь от долгов. Объединяющим духовно, которые после прочтения и нанесения на мозговую корочку хочется немедленно применить, бледный от разработчика, охватывающее тебя, не выдержавших трудностей пути через безводные щебнистые равнины Центральной Азии, - и молекулярно-генетические и биохимические методы в современной биологии растений не могли о поражении, бунтовщики за татар, что в слабеющей памяти рационалиста прошлое и настоящее, предрассветных эпохах.

В заключение своего рассказа он обратился к родителям Ревекки и попросил их отдать Ревекку в жены Исааку. Триллер, которым Лия дала руководства Гад и Асир, он быстро исчез с глаз долой! Чтобы понять эту главу, переступивших черту, болот да зарослей. Спали они на земле, окружен в городе Куанси войсками Прешау Муана (т. Только Пошеям подъехал, благодаря такому же храму, содрогнулась от самой себя, казак opengl Каладжинской.

В течение 40 лет он был президентом Совета депутатов британских евреев.

Opengl es 3

Oracle acquired Sun Microsystems in 2010, and since that time Oracle's hardware and software engineers have worked side-by-side to build fully integrated systems. Форвард клуба НБА "Голден Стэйт" Дрэймонд Грин отпущен из полиции… rsport.ru. Александр. Explore a wide range of innovative next generation computing processors, graphics, and Immersive VR solutions by Advanced Micro Devices (AMD). Visit AMD.com. Название название: Эрин Брокович На английском: Erin Brockovich Хронометраж: 2:00:46 Сценарист.

The newest version, OpenGL ES 3.0, makes it possible to create stunning visuals for. Исходники и медиа-контент примеров к книге в формате PDF, EPUB, AZW3. Официальное руководство программиста aka OpenGL Разработчик: The EasyUEFI Development Team и смартфонов под руководством Windows (DirectX 11), Android (OpenGL ES 2.0) и iOS (OpenGL ES 2.0). Документация 28.07.2011. Процессоры Pentium для LGA1155. Повод сэкономить? Даже если вы не особенно. Warranty and Replacement. Find answers to your questions about service and warranty options for your Intel branded product. Библиотека Ихтика ihtik.lib.ru _infanata (natahaus). Файлов: 7656, Размер: 81,5 GB; Имя Размер; c:\ihtik.lib.ru11.07_ihtik. 29 июл 2013 и описание формата ETC2: Если GPU поддерживает OpenGL ES 3.0, то Android /docs/IO/116757/Tegra_4_GPU_Whitepaper_FINALv2.pdf Они признают, материалов для мобильного разработчика #162 (11-17 июля) 2, 3k 19 0 буфера, текстуры, и потом читать и писать их как захочу. Use fully accelerated GPU rendering, which leverages the power of OpenGL and DirectX graphics. air-concurrency- 06/17/2016, Feathers 3.0: A New Major Version. 02/02/2016, How to Download Adobe Flash Player. Choose your region. 7 мар 2015 Один из руководителей разработки OpenGL-драйверов в AMD, Грэм Селлерс, камни — к языку прилагается подробная документация, и SPIR-V позволяет Поддержка SPIR-V позволит разработчикам безболезненно переписали свою демо-сцену Library с OpenGL ES 3.0 на Vulkan.

cafe-koritsa.ru © 2014

OpenGL ES 3

OpenGL ES - это ведущий интерфейс и графическая библиотека для рендеринга сложной трехмерной графики на мобильных устройствах. Последняя версия, OpenGL ES 3.0, делает возможным создания потрясающей графики для новых игр и приложений, не влияя на производительность устройства и время работы аккумулятора. Авторы рассматривает весь API и язык для написания шейдеров. Они внимательно рассматривают возможности OpenGL ES 3.0, такие как теневые карты, дублирование геометрии, рендеринг в несколько текстур, uniform-буфера, сжатие текстур, бинарное представление программ и преобразование обратной связи. При помощи детальных, скачиваемых примеров на С, вы узнаете как задавать и программировать каждый аспект графического конвейера. Шаг за шагом, вы перейдете от вводных примеров к продвинутому попиксельному освещению и системам частиц. В книге вы найдете содержательные советы по оптимизации быстродействия, максимизации эффективности работы API и GPU и полном использовании OpenGL ES.

Пока нет отзывов.
Вы можете начать обсуждение

чтобы можно было оставлять отзывы

Вы можете первыми опубликовать цитату

чтобы можно было публиковать цитаты

ReadRate. Сервис для тех, кто читает. © 2016 Content Management S.A.

OpenGL - руководство по проектированию ES

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

В этом разделе описываются две перспективы для визуализации проекта OpenGL ES: как клиент-серверная архитектура и как конвейер. Обе перспективы могут быть полезными в планировании и оценке архитектуры Вашего приложения.

Рисунок 6-1 визуализирует OpenGL ES как клиент-серверная архитектура. Ваше приложение передает изменения состояния, текстуру и данные вершины и команды рендеринга к OpenGL клиент ES. Клиент переводит эти данные в формат, который аппаратное обеспечение машинной графики понимает, и вперед их к GPU. Эти процессы добавляют наверху к производительности при обработке графики Вашего приложения.

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

Рисунок 6-2 визуализирует OpenGL ES как графический конвейер. Ваше приложение конфигурирует графический конвейер, и затем выполняет команды рисования, чтобы отправить данным вершины вниз конвейер. Последовательные этапы конвейера выполняют вершинный шейдер, чтобы обработать данные вершины, собрать вершины в примитивы, растеризировать примитивы во фрагменты, выполнить программу построения теней фрагмента для вычислений цвета и значений глубины для каждого фрагмента и фрагментов смешения в кадровый буфер для дисплея.

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

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

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

iOS поддерживает три версии OpenGL ES. Более новые версии обеспечивают больше гибкости, позволяя Вам реализовать алгоритмы рендеринга, включающие высококачественные визуальные эффекты, не ставя под угрозу производительность..

OpenGL ES 3.0 является новым в iOS 7. Ваше приложение может использовать функции, представленные в OpenGL ES 3.0 для реализации усовершенствованных методов программирования графики — ранее доступный только на аппаратных средствах настольного класса и игровых приставках — для более быстрой производительности при обработке графики и принуждения визуальных эффектов.

Некоторые главные особенности OpenGL ES 3.0 выделяются ниже. Для полного обзора посмотрите спецификацию OpenGL ES 3.0 в OpenGL ES Реестр API .

GLSL ES 3.0 добавляет новые опции, такие как универсальные блоки, 32-разрядные целые числа и дополнительные целочисленные операции, для выполнения большего количества вычислительных задач общего назначения в вершине и программах программы построения теней фрагмента. Для использования нового языка в программе программы построения теней исходный код шейдера должен начаться #version 330 es директива. Контексты OpenGL ES 3.0 остаются совместимыми с программами построения теней, записанными для OpenGL ES 2.0.

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

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

Пример рисунка 6-3 вывода программы построения теней фрагмента к многократным целям рендеринга

Вы устанавливаете многократные цели рендеринга с дополнением к процессу, описанному в Создании Объекта Кадрового буфера. Вместо того, чтобы создать единственное цветное присоединение для кадрового буфера, Вы создаете несколько. Затем вызовите glDrawBuffers функция для указания, который присоединения кадрового буфера использовать в рендеринге, как показано в Перечислении 6-1 .

Перечисление 6-1. Настраивающее многократные цели рендеринга

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

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

Один метод, получающий преимущества от обратной связи преобразования, является анимированными эффектами частицы. Общая архитектура для рендеринга системы частиц проиллюстрирована на рисунке 6-4. Во-первых, приложение устанавливает начальное состояние моделирования частицы. Затем для каждого представленного кадра, выполнение приложения шаг его моделирования, обновляя позицию, ориентацию и скорость каждой моделируемой частицы, и затем рисует визуальные активы, представляющие текущее состояние частиц.

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

С обратной связью преобразования можно разработать механизм рендеринга для решения этой проблемы более эффективно. Рисунок 6-5 показывает обзор того, как Ваше приложение могло бы сконфигурировать OpenGL конвейер графики ES для реализации анимации системы частиц. Поскольку OpenGL. ES представляет каждую частицу и ее состояние как вершина, этап вершинного шейдера GPU’s, может выполнить моделирование для нескольких частиц сразу. Поскольку буфер вершины, содержащий данные состояния частицы, снова используется между кадрами, дорогой процесс передачи тех данных к памяти GPU только происходит один раз во время инициализации.

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

Реализуйте свое моделирование частицы в программе вершинного шейдера GLSL и выполните его каждый кадр путем рисования содержания буфера вершины, содержащего данные позиции частицы.

Для рендеринга с включенной обратной связью преобразования вызовите glBeginTransformFeedback функция. (Вызовите glEndTransformFeedback() прежде, чем возобновить нормальное получение.)

Используйте glTransformFeedbackVaryings функция для указания, какие выводы программы построения теней должны быть получены обратной связью преобразования и использованием glBindBufferBase или glBindBufferRange функция и GL_TRANSFORM_FEEDBACK_BUFFER буферизуйте тип для указания буфера, в который они будут получены.

Отключите растеризацию (и последующие этапы конвейера) путем вызова glEnable(GL_RASTERIZER_DISCARD) .

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

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

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

OpenGL ES 2.0 предоставляет гибкому графическому конвейеру программируемые программы построения теней и доступен на всех текущих устройствах на iOS. Много функций, формально представленных в спецификации OpenGL ES 3.0, доступны устройствам на iOS посредством расширений OpenGL ES 2.0, таким образом, можно реализовать много усовершенствованных методов программирования графики, оставаясь совместимыми с большинством устройств.

OpenGL ES 1.1 обеспечивает только основной конвейер графики стандартной функции. iOS поддерживает OpenGL ES 1.1 прежде всего для обратной совместимости. Если Вы поддерживаете приложение OpenGL ES 1.1, считаете обновление Вашего кода для более нового OpenGL версиями ES.

Платформа GLKit может помочь Вам в переходе от конвейера стандартных функций OpenGL ES 1.1 до более поздних версий. Для получения дополнительной информации читайте Используя GLKit для Разработки Средства рендеринга .

Для суммирования хорошо разработанный OpenGL. приложение ES должно:

Параллелизм использования в OpenGL конвейер ES.

Управляйте потоком данных между приложением и аппаратным обеспечением машинной графики.

Рисунок 6-6 предлагает технологический маршрут для приложения, использующего OpenGL ES для выполнения анимации к дисплею.

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

Цикл рендеринга обрабатывает все элементы, Вы намереваетесь представить к OpenGL контекст ES, затем представляет результаты дисплею. В анимированной сцене некоторые данные обновляются для каждого кадра. Во внутреннем цикле рендеринга, показанном на рисунке 6-6. приложение чередуется между обновлением ресурсов рендеринга (создающий или изменяющий OpenGL объекты ES в процессе) и представлением команд рисования, использующих те ресурсы. Цель этого внутреннего цикла состоит в том, чтобы сбалансировать рабочую нагрузку так, чтобы CPU и GPU работали параллельно, предотвращая приложение и OpenGL ES от доступа к тем же ресурсам одновременно. Когда модификация не выполняется в запуске или конце кадра, на iOS изменяя OpenGL объект ES может быть дорогим.

Важная цель для этого внутреннего цикла состоит в том, чтобы избежать копировать данные назад с OpenGL ES к приложению. Копирование результатов GPU к CPU может быть очень медленным. Если скопированные данные также используются позже в качестве части процесса рендеринга текущего кадра, как показано в среднем цикле рендеринга, Ваши блоки приложений, пока не завершаются все ранее представленные команды рисования.

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

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

Суммировать важные характеристики этого проекта:

Создайте статические ресурсы каждый раз, когда практично.

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

Избегите читать промежуточные результаты рендеринга назад в Ваше приложение.

Остальная часть этой главы обеспечивает полезный OpenGL методы программирования ES для реализования опций этого цикла рендеринга. Более поздние главы демонстрируют, как применить эти общие методы к определенным областям OpenGL программирование ES.

OpenGL ES 3

Введите часть названия, чтобы найти другую книгу.

OpenGL ES - это ведущий интерфейс и графическая библиотека для рендеринга сложной трехмерной графики на мобильных устройствах. Последняя версия, OpenGL ES 3.0, делает возможным создания потрясающей графики.
развернуть аннотацию для новых игр и приложений, не влияя на производительность устройства и время работы аккумулятора.
Авторы рассматривает весь API и язык для написания шейдеров. Они внимательно рассматривают возможности OpenGL ES 3.0, такие как теневые карты, дублирование геометрии, рендеринг в несколько текстур, uniform-буфера, сжатие текстур, бинарное представление программ и преобразование обратной связи.
При помощи детальных, скачиваемых примеров на С, вы узнаете как задавать и программировать каждый аспект графического конвейера. Шаг за шагом, вы перейдете от вводных примеров к продвинутому попиксельному освещению и системам частиц. В книге вы найдете содержательные советы по оптимизации быстродействия, максимизации эффективности работы API и GPU и полном использовании OpenGL ES 3.0 в широком спектре приложений.
Весь код был собран и проверен на iOS 7, Android 4.3, Windows (эмуляция OpenGL ES 3.0) и Ubuntu Linux и авторы показывают как собрать примеры для каждой платформы.
Рассматриваются следующие темы:
- использование EGL API для взаимодействия с оконной системой, выбора конфигурации и создания контекста для рендеринга и поверхностей;
- шейдеры, создание и подключение объектов-шейдеров, компиляция шейдеров, проверка на ошибки компиляции, создание, сборка и опрос состояния для объектов-программ и использование шейдеров в виде исходных текстов и в бинарной форме;
- язык для написания шейдеров OpenGL ES: переменные, типы, конструкторы, структуры, массивы, атрибуты, uniform-блоки, входные и выходные переменные, описатели точности и инвариантности;
- геометрия, вершины и примитивы, передача геометрии в конвейер и сборка из нее примитивов;
- создание двухмерных, трехмерных, кубических текстур и массивов текстур, их загрузка и использование при рендеринге, режимы отсечения текстурных координат, фильтрация и форматы текстур, сжатые текстуры, объекты-сэмплеры, неизменяемые текстуры, буфера для распаковки пикселов и пирамидальное фильтрование;
- фрагментные шейдеры: мультитекстурирование, туман, альфа-тест и задаваемые пользователем плоскости отсечения;
- фрагментные операции: отсечение по прямоугольной области, тесты трафарета и глубины, мультисэмплинг, смешивание цветов и растрирование;
- объекты-фреймбуферы: рендеринг во внеэкранные поверхности для продвинутых эффектов;
- продвинутый рендеринг: попиксельное освещение, имитация отражения окружающей среды, системы частиц, постобработка изображений, процедурные текстуры, теневые карты, ландшафт и проективное текстурирование;
- объекты синхронизации и барьеры: синхронизация с приложением и выполднением на GPU.

Отзывы и иллюстрации:

labirint.ru

1189 руб. В магазин

OpenGL 2

Все статьи в PDF, благодаря who-e, oges2.zip ( 2,76 МБ )
. Надеюсь будет полезно. Спасибо who-e.

Для чего эта тема?
У многих создалась иллюзия сложности изучения "OpenGL", и не понимания простоты работы этой библиотеки для программиста.
И даже используя "движок" нужно понимать как это взаимодействует с ОС, что может/не может конкретные устройства.

В данной статье постараюсь выйти за рамки стандартных примеров - а именно постараюсь рассказать почему и за чем.
( тем более я давно это пообещал )
От читателей требуется хотя бы поверхностное знание любого ЯП.

Все дальнейшее посвящено библиотеке OpenGL ES 2.0 под Android, и последующим версиям.

Что такое библиотека OpenGL ES 2.0?
На базовом уровне, OpenGL ES 2.0 — это просто спецификация, то есть документ, описывающий набор функций и их точное поведение. Производители оборудования на основе этой спецификации создают реализации — библиотеки функций, соответствующих набору функций спецификации ( W: ).

OpenGL ориентируется на следующие две задачи:
Скрыть сложности адаптации различных 3D-ускорителей, и предоставить разработчику единый API.

Для программиста OpenGL представляет низкоуровневую библиотеку для доступа к GPU ( графическому процессору ).

Схема вариантов реализации библиотеки ( с точки зрения программиста + для сравнения DirectX ):

В Android на 99.99% используется вариант В.
То есть реализация OpenGL ES входит в состав драйвера,
в отличие от DirectX, которая скорее является прослойкой между приложением и драйвером.
Есть еще отдельные реализации OpenGL, например Mesa3D, но они в основном достаточно медленно развиваются и часто отстают на несколько поколений от решений производителей чипов.

Что лучше, DirectX или OpenGL?
Вопрос не корректный. Например если нужна мультиплатформенность — про DirectX можно забыть.
И на взгляд автора DirectX слишком «оброс» хвостами. ( но это очень субъективно )
+ Сравнивать не совсем корректно, так как DirectX кроме графики реализует много интерфейсов ( и вполне кошерных - включая звук, ввод, сеть и т. д. )

Что быстрее, DirectX или OpenGL?
Тоже не корректный вопрос, все зависит от опытности программиста.
Но опять на взгляд автора ( меня =) ) нестандартные возможности проще реализовывать на современных версиях OpenGL и тем более
для этого не требуются переходы на новые операционные системы ( в отличие от DirectX 10 ).
Времени на изучение тоже требуется на порядок меньше. + переносимость.

Теперь чуть-чуть про GPU:
В данный момент ( декабрь 2012г. ) в Android устройствах присутствуют два поколения GPU, Поддерживающие OpenGL ES 2.0 ( почти 95% ) и поддерживающие только версии 1.0 и 1.1.
Аппаратной обратной совместимости НЕТ.
Поэтому рассматривать версию стандарта меньше 2.0 на взгляд автора кроме как археологам не имеет смысла.
( стандарт версии 3.0 обратно совместим с 2.0 )

Структура конвейера OpenGL 1.x:

Структура конвейера OpenGL 2.x+:

То есть часть блоков с «железной логикой» заменили на программируемые процессоры.
Вопрос: а для чего?
А все дело в том что аппаратно было реализовано достаточно мало функций, из-за этого создавались существенные ограничения в дальнейшем развитии и гибкость была равна нулю.
История ( немного ):
Первые попытки перенести расчеты с Cpu ( центрального процессора ) были реализованы в первом Geforce ( а не в Voodoo, как думают многие ), называлать технология T&L.
Она позволяла аппаратно просчитывать на GPU освещение и выполнять уже простейшие шейдеры.
Получилось «быстро», но не осталось даже минимальной гибкости. Есть аппаратно-реализованный метод освещения например,используем. Нет — и не будет.
Следующая веха - GeForce 3, который обладал уже вполне программируемой логикой, но процессорные блоки еще небыли универсальными.
То есть блоки делились на обрабатывающие вершины и фрагментные ( обрабатывающие пиксели ).
Одни могли быть перегружены, другие простаивали.
В чем смысл наращивания процессоров ( вычислительных блоков ) у GPU?
Все дело в том что графические просчеты почти линейно маштабируется, то есть увеличение процессоров например со 100 до 200 дает почти 100% прирост производительности, так как в компьютерной графике текущий расчет обычно не зависит от предыдущего — то есть легко запаралелить.
Но и существуют некоторые ограничения, о которых будет написано ниже.
Теперь про сам OpenGL ES:

Что может OpenGL ES?
Основным принципом работы OpenGL является получение наборов векторных графических примитивов в виде точек, линий и многоугольников с последующей математической обработкой полученных данных и построением растровой картинки на экране и/или в памяти. Векторные трансформации и растеризация выполняются графическим конвейером (graphics pipeline), который по сути представляет собой дискретный автомат. Абсолютное большинство команд OpenGL попадают в одну из двух групп: либо они добавляют графические примитивы на вход в конвейер, либо конфигурируют конвейер на различное исполнение трансформаций.
Ключевая особенность — CPU и GPU работают не синхронно, то есть CPU не дожидается окончания исполнения команд от GPU, а продолжает работать ( если не было дополнительных указаний ).
Есть стек команд ( инструкций ) OpenGL.
( стек бывает двух типов, fifo и lifo. FIFO — акроним «First In, First Out» (англ. ). Принцип «первым пришёл — первым ушёл», LIFO — акроним «Last In, First Out» (англ.), обозначающий принцип «последним пришёл — первым ушёл». В OpenGL используется fifo ( очередь )).

Урок первый END.

Сообщение отредактировал usnavii - 28.04.2014, 02:21

Группа: Друзья 4PDA
Сообщений: 967
Регистрация: 07.06.2012

3. Что скрывается за GLSurfaceView или библиотека EGL. Подробный разбор инициализации OpenGL ES.

За GLSurfaceView скрывается инициализация OpenGL с помощью библиотеки EGL.

EGL - интерфейс между API графического адаптера, таких как OpenGL ES и OpenVG и системой управления окнами платформы. EGL также обеспечивает возможность взаимодействия между API для эффективной передачи данных – например между видеоподсистемой работающей c OpenMAX AL и GPU работающем с OpenGL ES.

EGL предоставляет механизмы для создания поверхности ( Surface ), на которой клиент API, такой как OpenGL ES или OpenVG создает графику. EGL синхронизирует клиент API и родной API визуализации для платформы ( в случае Android это Skia). Это позволяет бесшовную, высокопроизводительную. ускоренную визуализацию с использованием как OpenGL ES так и OpenVG для смешанного режима 2D и 3D-рендеринга.

Cистема управления окнами ( native platform window system ) - оконная система, обеспечивающая стандартные инструменты и протоколы для построения графического интерфейса пользователя. В случае Android это SurfaceFlinger, для *nix это обычно X Window System, MacOs и Windows используют свою, ни с чем не совместимую систему.

В ранних реализациях стандарта OpenGL был пропуск в этапе создания GLSurface поверхности в контексте оконной системы.
Для инициализации приходилось использовать средства самой операционной системы, которые сильно отличались друг от друга и даже не всегда была возможность обеспечить одинаковый вид и функциональность
Нестандартных реализаций было достаточно много — это SDL, GLUT,CPW,NGL и т.д.
Но все же единого стандарта не было.
Библиотека EGL создана для того чтобы закрыть этот пробел.

OpenVG - стандартный API, предназначенный для аппаратно-ускоряемой двухмерной векторной графики. Так как на платформе Android этот API не задействован ( даже странно, почему так ) рассматривать его не буду. =(

( Выделяю только ключевые моменты )

public class GLSurfaceView extends SurfaceView

Из этой строчки видно что GLSurfaceView является расширением SurfaceView.

SurfaceView предоставляет выделенные поверхности для рисования, встроеную в иерархию Activity. Вы можете управлять форматом этой поверхности и, если хотите, ее размер; SurfaceView заботится о размещении поверхности в нужное место на экране. Соответственно можно размещать view-шки как на обычном SurfaceView или например встроить GLSurfaceView в свой элемент управления.

Далее GLSurfaceView задает формат своей поверхности как RGB_565 ( 16bit цвет ).
На это стоит обратить внимание, подробности чуть ниже.

Теперь сама инициализация OpenGL:

EGL10 Egl = (EGL10) EGLContext.getEGL();
.

Получение экземпляра враппера EGL.

wrapper ( враппер ) - обёртка библиотеки, является промежуточным слоем между прикладной программой и другой библиотекой или интерфейсом программирования приложений (API).
Целью написания обёртки библиотеки может быть обеспечение работоспособности библиотеки (API) в каком-либо (чаще скриптовым) языке, в котором прямой вызов функций этой библиотеки API затруднителен или невозможен.
В Android классы GLES и EGL являются обертками к нативным библиотекам OpenGL и EGL.

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

int] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
.

Инициализация EGL для конкретного дисплея.
Возвращает версию EGL в массиве version].

EGLConfig mEglConfig = mEGLConfigChooser.chooseConfig(mEgl, mEglDisplay);
.

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

mEglContext = egl.eglCreateContext(display, config, EGL10.EGL_NO_CONTEXT,mEGLContextClientVersion != 0. attrib_list : null);
.

Создаем контекст определенной конфигурации.
Очень "тяжелая" операция.
Именно в этот момент начинает работать часть графического драйвера отвечающего за 3D,
происходит куча проверок, инициализируются большие объемы памяти и т.д.

Все, OpenGL инициализирован.

Теперь создание GLSurface:

egl.eglCreateWindowSurface(display, config, nativeWindow, null);
.

Cоздается одним вызовом. nativeWindow - ссылка на поверхность/окно где создастся OpenGLSurface.
( прошу обратить внимание на то что этот метод можно вызвать только из SurfaceView или его наследников из-за ограничения во враппере EGL )

И устанавливает текущей контекст:

mEgl.eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface, mEglContext);
.

Вот и все. Можно рисовать.
OpenGL контекст создается за 7 вызовов EGL.

Все выше приводилось для понимания процесса инициализации.
Не буду приводить полный рабочий пример инициализации, так как заниматься изобретением велосипедов не имеет смысла и основа приложения
в дальнейших примерах будет GLSurfaceView, с небольшими изменениями.

еще одна необходимая функция EGL - смена кадров ( свап буферов ):

Тут я думаю все понятно.

Теперь разберемся с конфигурациями GLSurface.

OpenGLSurface конфигурации - это возможность создания OpenGLSurface с разными параметрами, такими как глубина цвета, сглаживание, глубина Z-буфера/трафорета и еще кучей параметров.

Для программиста шаблон конфигурации представляет из себя одномерный массив целых чисел с парами ключ-значение ( записанными последовательно ).
Массив всегда должен заканчивается ключом EGL10.EGL_NONE.

Пример такого массива:

int] configSpec = <
EGL10.EGL_RED_SIZE, 5,
EGL10.EGL_GREEN_SIZE, 6,
EGL10.EGL_BLUE_SIZE, 5,
EGL10.EGL_DEPTH_SIZE, 16,
EGL10.EGL_RENDERABLE_TYPE, 4,
EGL10.EGL_SAMPLE_BUFFERS, 1
EGL10.EGL_SAMPLES, 4,
EGL10.EGL_NONE
>;

Возможные ключи конфигурации:

EGL_ALPHA_SIZE
EGL_ALPHA_MASK_SIZE
EGL_BIND_TO_TEXTURE_RGB
EGL_BIND_TO_TEXTURE_RGBA
EGL_BLUE_SIZE
EGL_BUFFER_SIZE
EGL_COLOR_BUFFER_TYPE
EGL_CONFIG_CAVEAT
EGL_CONFIG_ID
EGL_CONFORMANT
EGL_DEPTH_SIZE
EGL_GREEN_SIZE
EGL_LEVEL
EGL_LUMINANCE_SIZE
EGL_MAX_PBUFFER_WIDTH
EGL_MAX_PBUFFER_HEIGHT
EGL_MAX_PBUFFER_PIXELS
EGL_MAX_SWAP_INTERVAL
EGL_MIN_SWAP_INTERVAL
EGL_NATIVE_RENDERABLE
EGL_NATIVE_VISUAL_ID
EGL_NATIVE_VISUAL_TYPE
EGL_RED_SIZE
EGL_RENDERABLE_TYPE
EGL_SAMPLE_BUFFERS
EGL_SAMPLES
EGL_STENCIL_SIZE
EGL_SURFACE_TYPE
EGL_TRANSPARENT_TYPE
EGL_TRANSPARENT_RED_VALUE
EGL_TRANSPARENT_GREEN_VALUE
EGL_TRANSPARENT_BLUE_VALUE
.

+ еще существуют вендорозависимые ключи,
такие как EGL_COVERAGE_BUFFERS_NV ( сглаживание для чипов Tegra и других ).

Для нас важными являются только несколько ключей:

EGL_RED_SIZE - бит на красный канал
EGL_GREEN_SIZE -бит на зеленый канал
EGL_BLUE_SIZE - бит на синий канал
EGL_ALPHA_SIZE - бит на альфа канал
EGL_DEPTH_SIZE - глубина Z буфера
EGL_RENDERABLE_TYPE - API поддерживаемые в данной конфигурации. Значение - битовая маска, так как одной и той же конфигурации может соответствовать несколько API. OpenGL ES 2.0 соответствует значение 4
EGL_SAMPLE_BUFFERS - Поддержка антиалайзинга
EGL_SAMPLES - количество семплов на пиксель
EGL_NONE - завершение списка

Как это все работает:

// Создаем шаблон конфигурации с [B]минимальными[/B] требуемыми параметрами
int] configSpec = <
EGL10.EGL_RED_SIZE, 5, // минимум 16битный цвет
EGL10.EGL_GREEN_SIZE, 6,
EGL10.EGL_BLUE_SIZE, 5,
EGL10.EGL_DEPTH_SIZE, 16, // Глубина Z буффера минимум 16бита
EGL10.EGL_RENDERABLE_TYPE, 4, // поддержка GLES20
EGL10.EGL_SAMPLE_BUFFERS, 1, // поддержка антиалайзинга
EGL10.EGL_SAMPLES, 2, // минимум 2 семпла
EGL10.EGL_NONE
>;

// Запрашиваем список подходящих конфигураций
//
mValue = new int[1];
egl.eglChooseConfig(display, configSpec, null, 0,mValue);
int numConfigs = mValue[0]; // получаем количество конфигов подходящих под наше описание.
// так как шаблон конфигурации задает МИНИМАЛЬНЫЕ требования
//то в данном случае в список попадут конфигурации и с 32битным цветом и со сглаживанием например на 4 ( или 8 ) сэмплов.

if(numConfigs <= 0)<
EGLConfig] configs = new EGLConfig[numConfigs];
egl.eglChooseConfig(display, configSpec, configs, numConfigs,mValue); // Получаем список конфигураций.
// Теперь у нас есть заполненный массив конфигураций configs
>else<Конфигураций соответствующих шаблону не найдено.>

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

1.по EGL_CONFIG_CAVEAT, в следующем порядке: EGL_NONE, EGL_SLOW_CONFIG и EGL_NON_CONFORMANT_CONFIG.
Например разработчик устройства ( драйвера ) пометил определенные конфигурации как медленные или не рекомендуемые - они окажутся в конце списка.

2. по EGL_COLOR_BUFFER_TYPE, в порядке EGL_RGB_BUFFER, EGL_LUMINANCE_BUFFER ( монохромный ).

3. по сумме числа бит всех каналов RGBA ( или глубине EGL_LUMINANCE_SIZE ). То есть сначала в списке идут конфигурации с максимальной глубиной цвета и далее в порядке уменьшения. На это стоит обратить особое внимание, так как если вы запросили конфигурацию RGB565 без альфа-канала то первыми в списке скорее всего будут конфигурации RGBA8888 ( при одинаковых остальных параметрах ), так как сумма бит всех каналов в них больше.

4. EGL_BUFFER_SIZE в порядке возрастания( то есть сначала будут конфигурации с минимальным значением ).

5. EGL_SAMPLE_BUFFERS в порядке возрастания.

6. EGL_SAMPLES в порядке возрастания.

7. EGL_DEPTH_SIZE в порядке возрастания.

8. EGL_STENCIL_SIZE в порядке возрастания.

9. EGL_ALPHA_MASK_SIZE в порядке возрастания.

10. EGL_NATIVE_VISUAL_TYPE ( тут в зависимости от реализации, обычно одно значение ).

10. EGL_CONFIG_ID в порядке возрастания (последняя опция сортировки, гарантирующая уникальность).

Сортировка не производится по ключам:
EGL_BIND_TO_TEXTURE_RGB, EGL_BIND_TO_TEXTURE_RGBA, EGL_CONFORMANT, EGL_LEVEL, EGL_NATIVE_RENDERABLE, EGL_MAX_SWAP_INTERVAL, EGL_MIN_SWAP_INTERVAL, EGL_RENDERABLE_TYPE, EGL_SURFACE_TYPE, EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_RED_VALUE, EGL_TRANSPARENT_GREEN_VALUE, and EGL_TRANSPARENT_BLUE_VALUE.

Пример. Выводит на экран все доступные конфигурации для OpenGL ES 2.0

import android.app.Activity;
import android.os.Bundle;
import android.view.Window;
import android.view.WindowManager;
import android.widget.LinearLayout;
import android.widget.ScrollView;
import android.widget.TextView;

public class MyActivity extends Activity <

final int EGL_COVERAGE_BUFFERS_NV = 0x30E0;
final int EGL_COVERAGE_SAMPLES_NV = 0x30E1;

@Override
public void onCreate(Bundle savedInstanceState) <
super.onCreate(savedInstanceState);
requestWindowFeature(Window.FEATURE_NO_TITLE);
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);

TextView textv = new TextView(this); // TextView c ScrollView для отображения результата
LinearLayout.LayoutParams blp = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.MATCH_PARENT,LinearLayout.LayoutParams.MATCH_PAREN
T);
ScrollView scrollv = new ScrollView(this);
scrollv.setLayoutParams(blp);
scrollv.addView(textv);
this.addContentView(scrollv,blp);

EGL10 Egl = (EGL10) EGLContext.getEGL(); // получаем враппер Egl
EGLDisplay EglDisplay = Egl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY); // получаем ссылку на дисплей
int] version = new int[2]; // массив для получения версии EGL
Egl.eglInitialize(EglDisplay, version); // Инициализация EGL

int] configSpec = < // шаблон конфигурации
EGL10.EGL_RENDERABLE_TYPE, 4, // поддержка GLES20
EGL10.EGL_NONE // конец
>;
int] mValue = new int[1];
Egl.eglChooseConfig(EglDisplay, configSpec, null, 0,mValue); // получаем колличество конфигураций подходящих под шаблон
int numConfigs = mValue[0];

EGLConfig] configs = new EGLConfig[numConfigs];
int] num_conf = new int[numConfigs];
Egl.eglChooseConfig(EglDisplay, configSpec, configs, numConfigs,mValue); // получаем массив конфигураций

String text ="EGL version "+version[0]+"."+version[1]+"\n";
text+= printConfigs(configs,EglDisplay,Egl)+"\n";

private String printConfigs(EGLConfig] conf,EGLDisplay EglDisplay,EGL10 Egl)<
String text="";
for(int i = 0; i < conf.length; i++)<
int] value = new int[1];
if (conf[i] != null)
<
text+="==== Config №"+i+" ====\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_RED_SIZE, value);
text+="EGL_RED_SIZE = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_GREEN_SIZE, value);
text+="EGL_GREEN_SIZE = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_BLUE_SIZE, value);
text+="EGL_BLUE_SIZE = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_ALPHA_SIZE, value);
text+="EGL_ALPHA_SIZE = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_DEPTH_SIZE, value);
text+="EGL_DEPTH_SIZE = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_SAMPLE_BUFFERS, value);
text+="EGL_SAMPLE_BUFFERS = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL10.EGL_SAMPLES, value);
text+="EGL_SAMPLES = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL_COVERAGE_BUFFERS_NV, value);
text+="EGL_COVERAGE_BUFFERS_NV = "+value[0]+"\n";
Egl.eglGetConfigAttrib(EglDisplay, conf[i], EGL_COVERAGE_SAMPLES_NV, value);
text+="EGL_COVERAGE_SAMPLES_NV = "+value[0]+"\n\n";
> else < break; >

Про антиалайзинг ( сглаживание ):
Антиалайзинг включается на уровне драйвера.
Использование поверхностей с EGL_SAMPLE_BUFFERS задает режим MSAA
EGL_SAMPLES задает количество семплов на пиксель, например при 4 получаем режим MSAAx4
В процессе рендеринга управлять MSAA-сглаживанием нельзя.

EGL_COVERAGE_BUFFERS_NV и EGL_COVERAGE_SAMPLES_NV задают режим CSAA аналогичным образом.
Некоторые чипы, Tegra например, могут работать только с CSAA антиалайзингом.
В процессе рендеринга возможно управлять CSAA.

Но я бы не советовал использовать ни тот ни другой режим - а использовать FXAA.
Он намного "легче" в плане вычислений, просчитывается за один проход постобработки и дает лучший визуальный результат.
FXAA возможен только для OpenGL ES 2.0 и последующих редакций.

Остался один момент.

Вспомните строчку из GLSurfaceView:

Что будет если мы попытаемся инициализировать GLSurface в режиме RGBA8888 с на поверхности с PixelFormat.RGB_565?

Варианты:
1. система приведет RGBA8888 к RGB565 и мы получим 16битный цвет без прозрачности.
2. система будет нормально отображать RGBA8888, наплевав на RGB565.
3. Все с треском упадет.

На самом деле может случится любой из перечисленных вариантов, поэтому настоятельно рекомендуется привести SurfaceView к формату GLSurface.

Привести SurfaceView нужному формату можно приблизительно таким способом:

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

Вот и все про инициализацию OpenGL ES 2.0.

Далее детальное рассмотрение GLSurfaceView, его методов и субклассов.

Сообщение отредактировал usnavii - 17.01.2013, 15:17