Вторник, 15.07.2025, 22:58
3d mir
Приветствую Вас Гость | RSS
Главная Регистрация Вход
Меню сайта

Главная » 2007 » Сентябрь » 30 » Open GL 3.0
Open GL 3.0
13:36
     Open GL 3.0       

Приблизительно год назад OpenGL-форумы были взбудоражены новостью – компании-производители графических ускорителей ATI и NVidia планируют внести радикальные изменения в API OpenGL. Новая версия графического интерфейса будет иметь версию 3.0.

На данный момент OpenGL – самый долгоживущий графический API, ему уже больше 14 лет (появился в 1992-1993 гг). За это время графическое оборудование постоянно изменялось и совершенствовалось. Поэтому неудивительно, что на данный момент ядро OpenGL уже не является реальной абстракцией аппаратных возможностей. Кроме того, все версии OpenGL имеют полную обратную совместимость (в отличие от Direct3D), которая со временем очень усложнила его спецификацию и реализацию драйвера.

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

Уже довольно давно велись разговоры о создании версии OpenGL, которая не будет обратно совместимой со старыми версиями, и предлагалось это сделать в версии 2.0. К сожалению эта идея была отброшена в пользу обратной совместимости, и OpenGL 2.0 увидел свет не таким, каким его некоторые ожидали – в ядро была добавлена поддержка шейдеров, появился OpenGL Shading Language, внесены незначительные коррективы в общую спецификацию. Революции не произошло. (К слову – удивительно, но в ядре OpenGL до сих пор не существует возможности вывода в текстуру – этим занимается расширение GL_EXT_framebuffer_object, которое ещё только планируется трансформировать в GL_ARB_framebuffer_object).

Две башни

ATI и NVidia работали сообща более полугода над предложением изменения направления OpenGL.
Большая часть времени была потрачена на общение с разработчиками программ с целью выянить, что они хотят видеть в новом OpenGL. В итоге, предлагаются почти те же идеи, которые предлагались для OpenGL 2.0, с одной лишь разницей – это предлагается сделать для OpenGL 3.0. Представители компаний ATI и NVidia были инициаторами рефакторинга OpenGL, а в данный момент этим вопросом занимается уже вся группа ARB (которая влилась в Khronos, и теперь предложенные ARB решения окончательно принимаются в Khronos Board of Promoters).

На данный момент в задачу ARB входит «издание» в 2007 году двух новых версий OpenGL. Первая, под кодовым именем OpenGL "Longs Peak" (позже должна получить номер версии), планируется к выходу этим летом. Вторая, под кодовым именем OpenGL "Mount Evans", должна выйти в Октябре 2007. Вполне определённые даты, не правда ли? Это вселяет надежду и уверенность. Почему кодовые имена? Да потому что планируется дать время группе маркетинга подумать над ними, т. к. предлагались самые различные варианты: OpenGL 2.2, OpenGL 3.0, OpenGL 3.1 и даже OpenGL 4.0! Т. к. сами API ещё не готовы и не время давать им номера, используются кодовые имена.

Приблизительно то, что год назад предлагалось реализовать как OpenGL 3.0, будет реализовано как OpenGL Longs Peak.  Тогда предлагалось сделать полный «clean break», т. е. сделать OpenGL 3.0 несовместимым со старыми версиями. Однако ISVs и некоторые IHVs высказались за сохранение совместимости. Поэтому было решено разделить OpenGL на два профиля. Первый, прозванный OpenGL Lean and Mean (OpenGL LM), является ядром API и представляет прямую абстракцию возможностей железа, обеспечивает оптимальную производительность. Второй – полный профиль, поддерживает всю существующую функциональность OpenGL, (т. е. следует запомнить – будет полная обратная совместимость со старыми версиями). Он будет выполнен в виде программной прослойки, в которой будут собраны старые и редко используемые возможности, размещённой вне драйвера. Как только произойдёт разделение, наибольшие усилия в будущем будут вкладываться в разработку LM-профиля. Кроме того, будет введена новая объектная модель, которая должна существенно увеличить производительность драйвера.

В то время как OpenGL Longs Peak будет реализовываться для текущего графического железа (предположительно NV4x, G7x, R5xx), OpenGL Mt. Evans предназначен для новейшего графического оборудования (G8x, R6xx и следующие за ними поколения). Он будет продолжением OpenGL Longs Peak со множеством новой функциональности. Среди них – новые виды программируемых шейдеров, централизованная роль буферов данных, поддержка целочисленных операций в OpenGL Shading Language и др.

Почему две версии OpenGL? Решено, что так будет проще для разработчиков. Если вы хотите разрабатывать приложения, совместимые со старым графическим оборудованием, можно использовать OpenGL Longs Peak, но программы также будут работать и на новом оборудовании. Чтобы задействовать все возможности будущего железа, необходимо использовать OpenGL Mt. Evans, который, однако, несовместим со старым оборудованием и предыдущими версиями OpenGL. Ситуация чем-то похожа на использование версий Direct3D 9 и 10, с тем лишь отличием, что привязки к операционной системе может и не быть.

OpenGL Longs Peak

Итак, OpenGL в том виде каким мы его знаем, будет разделён на два профиля. LM-профиль будет представлять собой ядро OpenGL (3.0?), тонкую абстракцию над графическим оборудованием. В нём будет устранена толстая прослойка между приложением и «железом», что уменьшит сложность драйверов и сделает их более быстрыми и свободными от багов. Можно будет писать полноценные приложения, используя только этот профиль. Вся устаревшая функциональность будет вынесена в программную прослойку, на которой будут держаться OpenGL приложения с полным профилем. Поощряться однако будет перенос приложений в сторону LM-профиля.

Следует отметить, что это планы годовалой давности, и некоторые из перечисленных ниже вещей могут попасть в Mount Evans, а не в Long Peaks.

Отрисовка геометрии

Какие возможности предлагается вынести в прослойку:

1) Непосредственный режим (glBegin, glEnd, glVertex, glTexCoord и т. д.)
2) Текущий vertex state
3) Массивы вершин, создаваемые не при помощи VBO
4) Включение массивов вершин (используя шейдеры, это должно делаться автоматически)
5) Списки отображения
6) Устаревшие команды, такие как glArrayElement(), glInterleavedArrays(), glRect()

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

Планируется добавить:

1) Геометрический инстансинг
2) Списки отображения только для геометрических данных (не будет GL_COMPILE_AND_EXECUTE, т. к. эта опция сложна для эффективной реализации)
3) Массивы вершин, включаемые в зависимости от текущего вершинного шейдера

Объекты состояний (State Objects)

Новые объекты будут инкапсулировать в себе множество состояний OpenGL, так, что можно будет переключаться между набором состояний за один вызов. Это будет заменой атрибутов в командах glPush/glPop. Совместно с VBO это должно будет работать очень эффективно. Такие объекты уже существуют в Direct3D 10.

Обработка вершин

Какие возможности предлагается вынести в прослойку:

1) Весь процесс фиксированной обработки вершин (трансформация и освещение)
2) Встроенные в GLSL переменные (gl_Vertex, gl_Normal и т. д.)

Обработка фрагментов

Какие возможности предлагается вынести в прослойку:

1) Текстурное окружение
2) Суммирование цветов
3) Туман

Планируется добавить:

1) Бесшовные кубические карты
2) Массивы текстур
3) Шейдеры, работающие с текстурными фильтрами

Растеризация примитивов

Какие возможности предлагается вынести в прослойку:

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

Планируется добавить:

В шейдере можно будет иметь доступ к значениям охвата (coverage values).

Расширение OpenGL Shading Language

1) Полная поддержка целочисленных типов данных и операций над ними – целочисленная операторы и математика, выборка из целочисленных текстуры, целочисленные вершинные атрибуты
2) Offline-компиляция шейдеров (уже присутствует в OpenGL ES)
3) Неизменяемая позиция вершины (замена ftransform())
4) Расширенный контроль над интерполяторами (flat/smooth, center/centroid, perspective correct/not correct). сentroid уже введён в GLSL 1.20
5) Доступ к ID вершины (функциональность G8x)
6) Привязывание текстур к самплерам (а не к текстурным блокам)

Дополнительно

Такая функциональность текущего OpenGL как color index rendering, accumulation buffer, evaluators, selection и feedback также будет вынесена в прослойку.

Кроме того, планируется расширить удобство при работе с новым API. Будет введён callback механизм для отлавливания ошибок, больше кодов ошибок (в стандартном OpenGL их всего 7), команда glInfoLog() для всех объектов, логи в более удобочитаемом виде.

Новая объектная модель

В новом OpenGL API будет существенно переработана объектная модель - менеджмент объектов будет значительно отличаться от того, который существует сейчас. Да, да, как и в старых версиях DirectX, в OpenGL тоже есть свои проблемы, пусть и менее явные. Новая объектная модель должна улучшить производительность драйвера, быть проще в использовании (более интуитивная, меньше вызовов команд), и болеё легкой в реализации для IHVs (что, в свою очередь, предполагает стабильность драйверов и упрощение жизни разработчиков приложений). В общем случае, она наверняка не будет уступать по производительности новому Direct3D 10 (а может, даже будет немного быстрее, как знать).

Существующая объектная модель развивалась в течении длительного промежутка времени и имеет несколько непоследовательный дизайн. Вначале были введены списки отображения в OpenGL 1.0, а затем – текстурные объекты в OpenGL 1.1. К сожалению, текстурные объекты были добавлены неоптимальным путём. Комбинация glBindTexture и glActiveTexture делает сложным отладку кода. Далее были добавлены новые типы объектов с иногда непоследовательной семантикой. Более того, существующая объектная модель оптимизирована для быстрого создания объекта, а не для производительной работы с ним в run-time. В большинстве случаев объект создаётся однажды и используется далее в работе, поэтому логичнее сделать так, чтобы объект был лёгок именно для рендеринга.

В текущей объектной модели приложения поставляют в API беззнаковое целое «имя», которое может генерироваться либо самим приложением, либо запросом к API (glGenLists, glGenTextures, glGenBuffers и т. д.). Когда это имя используется, реализация осуществляет выборку из хэш-таблицы, чтобы найти объект по этому имени. Далее объект привязывается (bind) для редактирования или использования. Объекты могут разделяться между контекстами.

Проблемы с использованием этой модели следующие:

1) Стоимость выборки из хэш-таблицы может добавлять 3-5% ко времени работы драйвера.
2) Процесс привязывания может быть причиной ошибок, из-за косвенного обращения (привязали объект в одной части программы, а его непреднамеренное редактирование может произойти совсем в другом месте).
3) Драйверу сложно провести оптимизацию, т. к. он не может предсказать, что вы будете делать с объектом.
4) Некоторые пробелы в поведении, например новое использование существующего имени.

Какие цели преследуются при разработке новой модели:

1) Достижение максимальной производительности в run-time.
2) Устранение незавершённых (incomplete) объектов (мне известны две проблемы – неполный набор MIP уровней в текстуре, и неполный набор буферов в FBO).
3) Разделение между контекстами на пообъектной основе (а не все объекты сразу)
4) Частичное устранение существующей семантики привязывания.

Что касается первого пункта, то здесь собираются пойти тем же путём, который используется в Direct3D 10. Т. е. максимальная производительность может быть достигнута только тогда, когда оверхед в OpenGL драйвере минимизирован. Существует несколько путей:

1) Количество проверок в реализации OpenGL, которые осуществляются в момент рисования (draw call), будет уменьшено. Сейчас, например, множество проверок могут происходить (и происходят) в момент рисования, замедляя скорость рендеринга.
2) Количество вызовов API для смены установок конвейера будет уменьшено, улучшая тем самым производительность. Например, количество операций привязывания или копирования значений юниформов будет снижено.
3) Новая модель уменьшит время, которое драйвер OpenGL затрачивает на поиск объекта по его имени.

Вместо используемых сейчас целочисленных имён, планируется создать новый тип, т. н. дескриптор объекта, размером как указатель в системе, на которой OpenGL запущен. Т. е:

typedef void *GLobject;

Это позволит (по выбору реализации) сохранять в дескрипторе указатель на структуру с внутренними данными, что позволит OpenGL быстро осуществлять к ним доступ (насколько я знаю, ранее существовали отдельные реализации OpenGL, в которых пытались использовать указатели под видом типа GLuint, но в документации по OpenGL где-то было писалось, что такая реализация не поощряется). Конечно, такой подход менее безопасен и может вызвать «падение» приложения. Предполагается ввести в OpenGL отладочный режим, в котором возможные ошибки при работе с объектами будут отлавливаться. Кроме того планируется, что для каждого объекта в OpenGL через typedef будет определён свой тип данных, что позволит проводить строгую проверку типов в compile-time. Это будет хорошим средством отладки, т. к. выдаваемые компилятором предупреждения будут индикаторами ошибок в программе.

Дескрипторы будут всегда генерироваться реализацией OpenGL. Такой дескриптор должен будет передаваться в каждую команду OpenGL, которая будет работать с объектом, который этот дескриптор описывает. Семантика «привязать для редактирования» и «привязать для использования» будет устранена. Нет ничего хорошего в том, чтобы устанавливать объект на конвейер только для того, чтобы отредактировать какое-то его свойство. Например:

glBindTexture(GL_TEXTURE_2D, texture);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, mag);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, min);

В таких случаях будет передаваться сам дескриптор texture, а привязывание (binding) будет осуществляться только тогда, когда объект действительно требуется для рендеринга. К слову, такой механизм уже был введён в шейдерные объекты OpenGL 2.0 – дескриптор генерируется командами glCreateShader/glCreateProgram, далее дескриптор передаётся как аргумент функции, а устанавливается программный объект как часть конвейера только командой glUseProgram. Теперь этот механизм будет обобщён и распространён на все команды API.

Создание любого объекта в OpenGL станет атомарной операцией. Все атрибуты, которые необходимы для создания объекта на сервере OpenGL, будут передаваться во время создания. После создания реализация возвращает дескриптор объекта. Атрибуты будут храниться в специальных шаблонах (template), которые будут расширяемыми, в случае появления новых расширений, добавляющих к объекту новые атрибуты. Как только шаблон создан, он будет хранить атрибуты по умолчанию. Атрибуты в шаблонах будут изменяемыми.

Атрибуты, передаваемые при создании объекта, будут неизменяемыми всё время существования объекта. Это значит, что эти свойства объекта впоследствии не смогут быть изменены. Например, текстура будет иметь такие неизменяемые параметры, как формат и размерность. Можно будет менять лишь сами текстурные данные. В отличие от этого, существующие вызовы glTexImage1D/2D/3D изменяют как текстурные данные, так и внутренний формат и размеры текстуры. Отделение формы и размеров текстуры от её данных поможет, например, драйверу лучше оптимизировать работу с памятью. Также устраняются проблемы с разделяемыми между контекстами объектами. Сейчас например, в документации неясно определено, как будет вести себя реализация OpenGL, если размерности текстуры, используемые в одном контексте, изменяются в другом контексте. Вы об этом не задумывались? А бывает оказывается и такое, и это головная боль для разработчиков драйверов.

Взбираясь на OpenGL Longs Peak

Не так давно появилась новая информация о важных решениях, которые приняло ARB относительно OpenGL Longs Peak:

1) Создание объектов будет асинхронной операцией. Это значит, что при вызове команды создания объекта она вернёт дескриптор ещё до того, как реальный объект будет создан реализацией OpenGL. «Крутость» этого подхода в том, что такой дескриптор – валидный и его можно использовать немедленно. Это открывает возможности параллельной работы приложения и реализации OpenGL, что является хорошей возможностью. Например, можно получить дескриптор текстуры, и далее выполнять какую-то другую работу. К тому времени, когда эта текстура понадобится для отображения, она уже будет создана на стороне сервера.
2) Множество привязываемых программных объектов. В OpenGL 2.1 на графический конвейер может устанавливаться только один программный объект. Это удобная модель, если присутствует только два программируемых этапа – вершинный и фрагментный, но она становится неудобной, если количество программируемых этапов увеличивается, т. к. количество возможных комбинаций этапов увеличивается и следовательно увеличивается количество необходимых программных объектов. В OpenGL Longs Peak станет возможно привязывать сразу несколько программных объектов для рендеринга. Каждый программный объект сможет хранить как один шейдер для одного программируемого этапа, так и несколько шейдеров для более чем одного программируемого этапа. Уже сейчас ясно, что добавлением в конвейер только геометрического шейдера дело не ограничится – мы увидим новые виды шейдеров, поэтому такая схема жизненно необходима.
3) Группы юниформных переменных можно будет объединять в блоки. Т. о. в шейдер можно будет передать сразу множество данных одним вызовом API. Также память для юниформов будет находиться в буфере, создаваемом приложением, и она сможет разделяться между множеством программных объектов. Подобная функциональность сейчас присутствует в OpenGL в виде расширения GL_EXT_bindable_uniform.

OpenGL Mount Evans

Разработкой этой версии OpenGL занимается отдельная группа в составе ARB - Next Gen TSG. Она будет продолжением Longs Peak и как уже было сказано, будет нацелена на использование совместно с новейшим графическим оборудованием. То, что можно прочитать из новостей ARB Next Gen TSG Update, свидетельствует об одном – в ядро будет включена большая часть функциональности G8x и R6xx. Разработка API ведётся на базе предложенных компанией NVidia расширений.

Год назал в OpenGL 3.0 (тогда, напомню, было одно направление, а не два) планировалось добавить т. н. texture shaders, sample shaders и primitive shaders. Первые два вида шейдеров станут доступны в будущих поколениях графических ускорителей, поэтому эта функциональность по идее должна попасть только в Mount Evans (для Direct3D её планируется добавить в DirectX 10.1).

Что должны заменить Texture Shaders:

1) Фильтры текстур
2) Режимы обёртки (wrap)
3) Режимы сравнения (для depth-текстур)
4) sRGB преобразования

Что должны заменить Sample Shaders:

1) Тест глубины
2) Тест трафарета
3) Операции смешивания (blend)

Из-за всего этого будут внесены значительные дополнения в OpenGL Shading Language,
сообщается что группа Shading Language TSG очень серьёзно занята этой проблемой.

Все новые возможности будут введены в виде новой объектной модели, представленной в OpenGL Longs Peak. Из-за зависимостей спецификация возможностей Mount Evans будет завершена через 2-3 месяца после того, как Object Model TSG завершит свою работу над Longs Peak.


Просмотров: 3332 | Добавил: Bignik | Рейтинг: 5.0/1 |
Всего комментариев: 1
1 Galduefeabals  
0
[url=http://silven.ru/khkhkh-onlajjn/]
русские онлайн смотреть бесплатное порно[/url]

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Форма входа

Календарь новостей
«  Сентябрь 2007  »
Пн Вт Ср Чт Пт Сб Вс
     12
3456789
10111213141516
17181920212223
24252627282930

Поиск

Друзья сайта

Статистика

Copyright MyCorp © 2025