Версии OpenGL и gpus - какая совместимость есть?

Question

Я пытаюсь понять, как версии видеокарт, версии OpenGL и заголовки API работают вместе. Я читал о разгроме OpenGL 2.0 / 3.0 / 3.1 на форумах OpenGL и в других местах, но до сих пор не ясно, как это сработает для меня как для разработчика (новичок в OpenGL). (Кстати, я использую nVidia в этом вопросе в качестве примера, потому что я покупаю одну из их карт, но, очевидно, я хотел бы быть независимым от поставщика для разрабатываемого мной программного обеспечения).

Во-первых, есть графический процессор, который должен поддерживать версию OpenGL. Но например У nVidia есть драйверы для старых видеокарт для поддержки OpenGL 3. Означает ли это, что эти драйверы реализуют определенные функции в программном обеспечении для эмуляции новых функций, которых нет в аппаратном обеспечении?

Тогда есть заголовки API. Если я решу написать приложение для OpenGL 3, должен ли я ждать, пока Microsoft выпустит обновленную версию SDK платформы с заголовками, которые поддерживают эту версию? Как вы выбираете, какую версию API использовать - через препроцессор, определяемый в коде, или выполняет обновление до последней версии SDK платформы, просто обновляя до последней версии (не могу представить этот последний вариант, но вы никогда не узнаете. ..).

А как насчет обратной совместимости? Если я напишу приложение, ориентированное на OpenGL 1.2, смогут ли пользователи, установившие драйверы для своей карты, поддерживающей OpenGL 3, по-прежнему запускать его, или я должен проверить функции / поддерживаемую версию карты в своем приложении? Чтение http://developer.nvidia.com/object/opengl_3_driver.html, кажется, подтверждает, что, по крайней мере, для карт nVidia приложения, написанные против 1.2, будут продолжать работать, но это также подразумевает, что другие поставщики могут прекратить поддерживать API 1.2. По сути, это поставит меня (потенциально) в такое положение в будущем, когда программное обеспечение не будет работать с последними картами, потому что они больше не поддерживают 1.2. Но если я сегодня разрабатываю для OpenGL 3 или даже 2, я могу исключить пользователей, которые поддерживают только gpu 1.2.

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

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

Answer 1

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

В Visual Studio вы всегда будете связывать свое приложение с opengl32.lib, и opengl32.lib не меняется в разных версиях OpenGL. Вместо этого OpenGL использует wglGetProcAddress () для динамического доступа к расширениям / версиям OpenGL во время выполнения, а не во время компиляции. А именно, если данный драйвер не поддерживает расширение, то wglGetProcAddress () вернет NULL во время выполнения, когда запрашивается процедура этого расширения. Таким образом, в вашем коде вам нужно будет реализовать логику, которая обрабатывает случай возврата NULL. В самом простом сценарии вы можете просто напечатать ошибку и сказать «эта функция недоступна, поэтому эта программа будет вести себя ...». Или вы можете найти другие альтернативные методы для того же, что не использует расширение. По большей части вы получите NULL-возврат от wglGetProcAddress только в том случае, если ваше приложение работает на старых аппаратных средствах / драйверах, которые не поддерживают версию OpenGL, в которой добавлено искомое расширение. Тем не менее, в последующие годы вы захотите быть в курсе тех вещей, которые новые версии OpenGL решили осудить. Я не слишком много читал в спецификации 3.1, но, видимо, они вводят модель устаревания, в которой устаревшие технологии / расширения могут быть устаревшими, что откроет дверь для новых аппаратных средств / драйверов, которые больше не будут поддерживать устаревшие расширения, и в этом случае wglGetProcAddress снова вернет NULL для этих расширений. Так что, если вы добавите логику для обработки возврата NULL в wglGetProcAddress (), все равно все будет в порядке даже для устаревших расширений. Возможно, вам просто потребуется внедрить лучшие альтернативы или установить новые расширения по умолчанию.

Что касается версионных заголовков API, то изменения в заголовках в основном являются просто изменениями, чтобы разрешить доступ к новым функциям, возвращаемым wglGetProcAddress (). Так что, если вы включите заголовок API для версии 2, вы можете продолжать, если вам нужны только расширения для OpenGL 2. Если вам нужен доступ к функциям / расширениям, которые были добавлены в версии 3, вы просто заменяете свою версию. Заголовок 2 с заголовком версии 3, который просто добавляет некоторые дополнительные указатели функций typedefs, связанные с новыми расширениями, так что при вызове wglGetProcAddress () вы можете привести возвращаемое значение к правому указателю функции. Пример:

PFNGLGENQUERIESARBPROC glGenQueriesARB = NULL;

...

glGenQueriesARB = (PFNGLGENQUERIESARBPROC)wglGetProcAddress("glGenQueriesARB");

В приведенном выше примере typedef для PFNGLGENQUERIESARBPROC определен в заголовках API. Полагаю, что glGenQueriesARB был добавлен в 1.2, поэтому мне понадобится как минимум 1.2 API-заголовка, чтобы получить определение PFNGLGENQUERIESARBPROC. Это действительно все заголовки.

Еще одна вещь, которую я хочу упомянуть о 3.1. Очевидно, что в версии 3.1 они устарели во многих функциях OpenGL, которые моя компания использовала довольно повсеместно, включая списки отображения, механизмы glBegin / glEnd и режим рендеринга GL_SELECT. Я не очень разбираюсь в деталях, но я не понимаю, как они могут это сделать, не создавая новый opengl32.lib для ссылки, потому что кажется, что большая часть этой функциональности встроена в opengl32.lib, и не доступен через wglGetProcAddress. Кроме того, собирается ли Microsoft включить этот новый opengl32.lib в свои версии Visual Studio? У меня нет ответа на эти вопросы, но я думаю, что, несмотря на то, что 3.1 устарела, эта функция будет существовать в течение длительного времени. Если вы продолжите связывание с вашим текущим opengl32.lib, он должен продолжать работать почти бесконечно, хотя в какой-то момент вы можете потерять аппаратное ускорение. Подавляющее большинство учебных пособий по OpenGL, доступных в Интернете, используют методы glBegin / glEnd для рисования примитивов. То же самое верно для GL_SELECT, хотя большая часть оборудования больше не ускоряет режим визуализации GL_SELECT. Даже в руководстве opengl.org используются предположительно устаревшие методы glBegin / glEnd. И я еще не нашел учебник по началу работы, который использует только функции 3.1, избегая устаревших функций (конечно, если кто-то знает одну, свяжите меня с ней). В любом случае, хотя кажется, что 3.1 выбрасывает много старого для всего нового, я думаю, что старое еще будет довольно долго.

Короче говоря, вот мой совет. Если ваши потребности OpenGL просты, просто используйте базовую функциональность OpenGL. Вершинные массивы поддерживаются в версиях 1.1 - 3.1, поэтому, если вы ищете максимальный срок службы и начинаете с нуля, это, вероятно, то, что вы должны использовать. Тем не менее, мое мнение - glBegin / glEnd, и списки отображения все еще будут присутствовать некоторое время, даже если они устарели в версии 3, поэтому, если вы хотите их использовать, я бы не стал слишком беспокоиться. Я бы избегал режима GL_SELECT для выбора в пользу альтернативного метода. Многие производители оборудования считали GL_SELECT устаревшим уже много лет, хотя он только устарел с версией 3. В нашем приложении мы сталкиваемся с множеством проблем, из-за которых он не работает на картах ATI и интегрированных картах GMA. Впоследствии мы только что реализовали метод выбора, используя запросы окклюзии, которые, кажется, решают проблему. Так что, чтобы сделать это правильно с первого раза, избегайте GL_SELECT.

Удачи.

Answer 2

Что касается драйверов, я думаю, что в некоторых случаях отсутствует функциональность, написанная программно. Весь смысл использования OpenGL (кроме ускорения) состоит в том, чтобы писать в API и не заботиться о том, КАК это реализовано.

По моему опыту, вы не объявляете версии OpenGL. Вызовы функций между версиями API не перекрываются. Помните о спецификации, и если, например, вы вызываете метод 2.0, минимальная версия вашего приложения просто станет 2.0. У меня есть приложения для отображения, написанные для целевой OpenGL (глупые старые видеокарты Sun), и она отлично работает на новых картах серии nvidia 200.

Я не думаю, что в любом случае можно гарантировать, что API не изменится в будущем; особенно если вы не контролируете это. Ваше приложение может перестать работать через 10 лет, когда мы находимся на OpenGL 6.4. Надеюсь, вы написали достаточно хорошее приложение, которое клиенты будут готовы платить за обновление.

Answer 3

Этот товарищ, MarK J. Kilgard, публикует исходный код и документы nVidia на openGL с 90-х годов и делает это от имени одного из двух крупнейших производителей игрового оборудования.

// --------------------------------------------- ---------------------------------------- ... представление о том, что приложение OpenGL «не подходит» для использования немедленного режима, является чрезмерно усердным. Спецификация OpenGL 3.0 зашла настолько далеко, что пометила немедленный режим в OpenGL как «устаревший» (что бы это ни значило!); такой экстремизм контрпродуктивен и глуп. Правильный способ поощрения правильного использования API - не пытаться осудить или запретить использование API, а скорее информировать разработчиков о правильном использовании API для конкретных ситуаций.