OpenGL: как обстоят дела с амортизацией?

Question

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

Может кто-нибудь объяснить, что на самом деле с этим связано?

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

Answer 1

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

Итак, они рисуют линию: если вы хотите использовать FF-шейдеры, вы не получите никакой новой функциональности. Если вы хотите новую функциональность, вы не можете использовать шейдеры FF. Это очень похоже на то, что Microsoft сделала в D3D10: она добавила целую кучу новых функций, но в то же время полностью удалила шейдеры с фиксированными функциями. Считается, что набор разработчиков, которым нужны новые функции без шейдеров, но которым также не нужны программируемые шейдеры, очень мал.

Answer 2

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

Полагаю, тогда Apple, должно быть, безумен, потому что MacOSX 10.7 поддерживает только 3.2 core . Нет поддержки спецификации совместимости, нет расширения ARB_compatibility, ничего. Вы можете создать контекст 2.1 или базовый контекст 3.2.

Однако, если вы хотите причины:

1. Ради полноты: что сказал Джесси Холл. ARB больше не должен учитывать взаимодействие между фиксированной функцией и новыми функциями. Целочисленная математика, текстуры массива и различные другие функции определены так, чтобы их нельзя было использовать с конвейером фиксированных функций. OpenGL действительно улучшился за последние 3 года с момента выхода GL 3.0; Темпы изменений АРБ довольно существенны. Было бы это возможно, если бы им нужно было найти способ заставить все эти функции взаимодействовать с фиксированной функцией? И если бы у них не было фиксированных взаимодействий функций, разве вы не стали бы жаловаться, как вы не можете получить доступ к новым функциям из старого кода? Который красиво ведет в:

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

3. Это делает возможное объединение рабочих столов GL и GL ES гораздо более разумным. ES 2.0 выбросил все старые вещи и просто принял то, что вы могли бы назвать ядром GL 2.1. Конечной целью будет иметь только один OpenGL. Чтобы сделать это, вы должны быть в состоянии избавить десктоп GL от всей грязи.

Answer 3

Следует уточнить, что функция, помеченная как "устаревшая", фактически не удаляется. Например, контекст OpenGL 3.0 обладает всеми функциями - ничего не пропало. Кроме того, некоторые поставщики поставляют драйверы, которые могут создавать контексты 3.1 и 3.2, используя профиль совместимости, который также включает устаревшие функции. Итак, внимательно посмотрите, какое оборудование поставщика вы собираетесь поддерживать, и спросите о режиме совместимости ARB для старых функций. (Существует также «базовый» профиль по состоянию на 3.2, который позволяет поставщикам создавать более скромный и подлый драйвер, если они желают создать такую ​​вещь)

Обратите внимание, что у любой текущей карты действительно нет секции аппаратного обеспечения FF - они только запускают шейдеры. Когда вы запрашиваете поведение FF, среда выполнения GL создает шейдеры от вашего имени.

Answer 4

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

Я менее уверен, чем вы, что они не будут исключены из большого количества аппаратного обеспечения в обозримом будущем, поскольку OpenGL ES 2.0 не поддерживает конвейер FF (и, следовательно, не обратно совместим с OpenGL ES 1.x) , Мне кажется, что большая часть импульса с OpenGL в наши дни исходит от широкого распространения OpenGL ES на мобильных платформах, и с отсутствием функциональности FF будет существенное давление, чтобы отказаться от его использования.

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

Answer 5

OpenGL допускает как «основной» профиль, так и «совместимый» профиль. Таким образом, для большинства систем вы не потеряете доступ к устаревшим или удаленным функциям.

Но если вы хотите обеспечить совместимость, лучше всего придерживаться основной темы. Вам не будет гарантирован профиль совместимости (даже если у большинства аппаратного обеспечения такой профиль есть, и в текущем состоянии более вероятно, что вы столкнетесь с устаревшим OpenGL, а не с основным ядром). Также OpenGL ES теперь является подмножеством OpenGL, можно написать программу OpenGL ES 2.x / 3.x и запустить ее в OpenGL 4.3 практически без изменений.

Игровые приставки, такие как PlayStations и Nintendo, поставляются с собственными графическими библиотеками, а не с OpenGL.

Они были основаны на OpenGL, но здесь урезаны аналогично ES (я не думаю, что ES 2.0 был тогда). Эти системы должны писать свои собственные графические драйверы и библиотеки, прося поставщика оборудования написать, что в целом представляет собой целую загрузку унаследованных библиотек обёртывания, немного (все функции фиксированных функций просто в конечном итоге будут реализованы в шейдерах и вполне вероятно, что в любом случае glBegin / glEnd будет автоматически превращаться в VBO).

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