Почему списки отображения не поддерживаются в opengl 3.1?

Question

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

Answer 1

Я думаю, хотя, возможно, я и ошибаюсь, поскольку большинство высокопроизводительных графических приложений (в основном игр) в основном используют только вершинные буферы и тому подобное (для того, чтобы выжать каждую каплю производительности из карты), чтобыло давление, чтобы перестать беспокоиться о «несерьезных» элементах, таких как списки отображения (и даже старые добрые вызовы glVertex).ИМХО, это создает огромный барьер для людей, которые учатся писать код OpenGL, и (для моих собственных целей) является большим препятствием для создания быстрого, разборчивого и достаточно эффективного кода.

Обратите внимание, что эти функциибыли объявлены устаревшими в 3.0 и фактически удалены в 3.1 (но все же обеспечивали совместимость через расширение ARB).В OpenGL 3.2 они переместили эти функции в профиль «совместимости», который необязателен для реализации авторами драйверов.

Так что это значит?По крайней мере, NVidia пообещала продолжить поддержку режима совместимости старой школы в обозримом будущем - существует большое количество устаревшего кода, который они должны поддерживать.Вы можете найти обсуждение их поддержки в слайд-шоу по адресу:

http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more

, начиная с слайда № 32.Я не знаю позицию ATI / AMD по этому вопросу, но я предполагаю, что она будет похожей.

Итак, хотя списки отображения технически удалены из необходимой части стандарта OpenGL 3.2, я думаю, что выбезопасно использовать их в течение достаточно долгого времени.В конце концов, вы можете изучить интерфейс OpenGL, ориентированный на буфер / шейдер, особенно если вашей конечной целью является написание конвертов, но это на самом деле намного менее интуитивно (даже без glRotate!), Поэтому я бы порекомендовалначиная с старого доброго OpenGL 2.x.

-matt

Answer 2

Списки отображения были удалены, потому что с opengl 3+ все данные о вершинах, текстурах и освещении хранятся на видеокарте в так называемом режиме рендеринга с сохранением (данные сохраняются, что позволяет вам отправлять одну карту на картурисовать сетку, а не отправлять данные вершин на карту каждый кадр).Основным узким местом в компьютерной графике является пропускная способность данных между ОЗУ и gpuRAM.генерируя сетки один раз и сохраняя эти данные, мы можем преобразовать их с помощью однородных матриц преобразования и легко их нарисовать.Это эффективно уменьшает узкое место с недостатком более длительного времени загрузки.Однако в немедленном режиме (до версии 3.0) для передачи вершинных данных в каждом кадре используется огромное количество графической полосы пропускания, предварительно преобразованной, с пересчитанными нормалями и т. Д. Проблемы с этим подходом имеют две стороны: 1) чрезмерное использование полосы пропускания и слишком большое время простоя графического процессора,2) Чрезмерное использование процессорного времени для вычислений, которые могут выполняться параллельно на 100+ ядрах, на графическом процессоре

. Простое решение для этого - режим с сохранением.

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

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

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

В Интернете есть несколько простых для понимания учебных пособий по opengl 3.0.После того, как вы опустите openGL 2.0, вам следует перейти на 3.0+, поскольку он позволяет создавать очень быстрые приложения для 3D-графики.

Answer 3

Хотя у Мэтью Холла есть хороший ответ и он охватывает большинство вещей, я добавлю несколько вещей.

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

Когда речь идет о том, какой контекст использовать, ну, это довы.Хотя, если производительность является серьезной проблемой, то, вероятно, следует использовать 3.x.Лично я определенно хочу изучать opengl 3.x, но я сомневаюсь, что откажусь от 1.x / 2.x.Просто гораздо проще собрать быстрое приложение с тем, что доступно в контексте 1.x или 2.x.

Если вы хотите получить список того, что устарело, скачайте спецификацию 3.0 и посмотрите в разделе «Модель обесценивания»

Answer 4

Замечание из будущего: последние версии Direct-X, Metal и Vulkan apis имеют буферы команд и очереди команд, которые позволяют записывать команды в ЦП, а затем отправляют их в графический процессор для их выполнения там. Таким образом, возможно, списки отображения не были настолько старомодной идеей. Фактически, компиляция списка отображения является чем-то ортогональным использованию шейдеров и VBO, и списки отображения могут еще больше повысить производительность ... Интересно, может ли транслятор Vulkan или Metal в OpenGL использовать списки отображения для буферов команд ....

Answer 5

Поскольку VBO (объекты буфера вершин) намного эффективнее и могут делать все, что могут делать списки отображения.Они на самом деле не более сложные, просто немного другие.Если вы уже не знакомы со старым стилем glBegin / glEnd, вам лучше всего узнать о буферах с самого начала.