VBO или списки отображения — совместимость с графическим процессором

Я работаю над новым приложением OpenGL и знаю, что списки отображения будут объявлены устаревшими в OpenGL 3.1 (наряду со многими другими полезными функциями, которые (мне) кажутся глупыми) и заменены объектами буфера вершин. Я успешно нарисовал треугольник с помощью VBO на карте NVidia, но пример не удалось запустить на чипе Intel на моем нетбуке, потому что он не поддерживает glGenBuffers. Кажется, в OpenGL есть существенный недостаток (нарушение совместимости между новыми и старыми графическими процессорами/GMA). Для малого бизнеса для моей игры необходима совместимость с максимально возможным количеством систем, но я не хочу, чтобы моя программа не работала на более новых видеокартах (из-за ее зависимости от списков отображения, которые были удалены из OpenGL 4.1). Спецификация). Что дало бы мне самую широкую поддержку видеокарт (старых и новых). Списки отображения или объекты буфера вершин?


person bbosak    schedule 03.05.2011    source источник


Ответы (3)


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

Если вы все еще беспокоитесь об эффективности, обязательно используйте glVertexPointer/glDrawArray, чтобы максимизировать размер партии. Это можно комбинировать со списками отображения, но это уменьшает количество отдельных операций в списке и, следовательно, делает эмуляцию менее проблематичной.

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

person Ben Voigt    schedule 03.05.2011
comment
Эмулируются ли они в драйверах, полностью удаляются из графического процессора (включая драйверы), или необходимо использовать «контекст совместимости», чтобы заставить его работать на графическом процессоре? - person bbosak; 04.05.2011
comment
@IDWMaster: поддерживается в драйверах, когда вы запрашиваете контекст совместимости (или старую версию OpenGL, если вы поддерживаете GMA, вы все равно должны использовать 1.5 или около того). Будет ли это 100-процентная эмуляция или частичное аппаратное ускорение, зависит от чипа, но в любом случае он должен соответствовать любой геометрии, с которой может справиться Intel GMA. - person Ben Voigt; 04.05.2011
comment
Спасибо! Не знал о функции glDrawArray! Это определенно должно улучшить производительность! Я приму ответ через 3 минуты. - person bbosak; 04.05.2011
comment
@IDWMaster: glDrawArray (или glDrawElements) также является частью VBO. Первоначально вы передавали указатели системной памяти на glVertexPointer, с VBO вы передаете указатель памяти графического процессора. Но общая структура кода одинакова. А с VBO или без него он обеспечивает значительное преимущество в производительности по сравнению с glBegin/glEnd. - person Ben Voigt; 04.05.2011
comment
@Ben: если вы поддерживаете GMA, вы должны использовать 1.5 или около того. Разве вы не оптимистичны! :) - person genpfault; 04.05.2011
comment
@genpfault: извините, версия 1.4 является самой высокой, поддерживаемой распространенными семействами GMA900 и GMA950. - person Ben Voigt; 05.05.2011

Ваша карта Intel поддерживает VBO, но только через интерфейсы ARB. Попробуйте glGenBuffersARB (вместе с преобразованием всего остального кода VBO для использования версий ARB). Он будет работать на nVidia и Intel GMA.

person Ben Jackson    schedule 03.05.2011
comment
Есть ли недостатки у интерфейса ARB по сравнению со стандартным? Почему существует два разных способа рисования VBO? - person bbosak; 04.05.2011
comment
Интерфейсы ARB были получены из предложения добавить новую функцию (совет по обзору архитектуры) и представлять интерфейсы до их окончательной доработки. В данном драйвере (который поддерживает оба) обычно интерфейс ARB и обычный интерфейс будут почти идентичны по поведению (при условии, что спецификация не сильно изменилась, когда предложение было принято). - person Ben Jackson; 04.05.2011
comment
@IDWMaster: Большинство функций OpenGL начинаются как расширения поставщиков, затем становятся расширениями, одобренными ARB, а затем, наконец, добавляются в будущий выпуск базовой спецификации. Это предотвращает загромождение основной спецификации неудачными функциями. Для расширений нет требований обратной совместимости, тогда как функции, принятые в ядро, остаются навсегда (по крайней мере, в профиле совместимости). - person Ben Voigt; 04.05.2011
comment
@IDWMaster: единственный фактический недостаток в этом конкретном случае заключается в том, что вам нужно проверить GL_EXTENSIONS для имени расширения (перед загрузкой указателей функций), и вам нужно ввести еще 3 символа для каждой функции и константы (хотя вы могли бы< /i> даже использовать имена, отличные от ARB). Это потому, что это конкретное расширение на 100% идентично основной функциональности, отличаются только имена символов. Все остальное, включая константы, одинаково (это не верно для каждого расширения). - person Damon; 04.05.2011

В качестве альтернативы вы можете запросить версию OpenGL, поддерживаемую системой, и использовать соответственно DisplayLists или VBO вместо того, чтобы полагаться на один метод, совместимый с каждой версией OpenGL. Таким образом, вы можете быть уверены, что используете самый современный, самый эффективный и быстрый способ рисования, независимо от того, какой метод (списки отображения/VBO) поддерживается системой.

Кроме того, такую ​​реализацию можно легко расширить для поддержки будущих методов рисования, скажем, в OpenGL 4.4 или OpenGL 5.0. Однако это может привести к тому, что несколько фрагментов кода будут функционально выполнять одно и то же: сообщать графическому процессору, что делать, что может увеличить размер и сложность кода.

person Jupiter    schedule 30.07.2013