Производительность WebGL и OpenGL

За последний месяц я возился с WebGL и обнаружил, что если я создаю и рисую большой буфер вершин, это вызывает низкий FPS. Кто-нибудь знает, если это будет то же самое, если я использовал OpenGL с С++?

Является ли это узким местом с используемым языком (JavaScript в случае WebGL) или графическим процессором?

WebGL примеры, подобные этому, показывают, что вы можете нарисовать 150 000 кубов, используя один буфер с хорошей производительностью, но что-то большее, чем это, я получаю капли FPS. Это будет то же самое с OpenGL, или он сможет обрабатывать более крупный буфер?

В принципе, я должен принять решение продолжить использование WebGL и попытаться оптимизировать код или - если вы скажете мне, что OpenGL будет работать лучше, а это узкое место на скорости языка, переключиться на С++ и использовать OpenGL.

Ответ 1

Если у вас есть только один вызов drawArrays, не должно быть большой разницы между OpenGL и WebGL для самого вызова. Однако настройка данных в Javascript может быть намного медленнее, поэтому это действительно зависит от вашей проблемы. Если основная часть ваших данных статична (ландшафт, комнаты), WebGL может работать хорошо для вас. В противном случае настройка данных в JS может быть слишком медленной для вашей цели. Это действительно зависит от вашей проблемы.

p.s. Если вы включите более подробную информацию о том, что вы пытаетесь сделать, вы, вероятно, получите более подробные/конкретные ответы.

Ответ 2

Анекдот, я написал игру на основе плитки в начале 2000 года, используя старый API стиля glVertex(), который работал совершенно гладко. Недавно я начал переносить его на WebGL и glDrawArrays(), а теперь на моем современном ПК, который по крайней мере в 10 раз быстрее, он получает ужасную производительность.

Похоже, причина в том, что я придумывал вызов go glBegin(GL_QUADS); glVertex()*4; glEnd(); с помощью glDrawArrays(). Использование glDrawArrays() для рисования одного многоугольника в WebGL намного медленнее, чем при использовании glVertex() в С++.

Я не знаю, почему это так. Может быть, это потому, что javascript - собака медленная. Возможно, это связано с некоторыми проблемами переключения контекста в javascript. Во всяком случае, я могу делать только 500 вызовов с одним полигоном glDrawArray(), все еще получая 60 FPS.

Кажется, что все вокруг работают, делая как можно больше на GPU и делая как можно меньше glDrawArray() вызовов за кадр. Можете ли вы это сделать, это зависит от того, что вы пытаетесь сделать. В примере с кубами, которые вы связали, они могут делать все на графическом процессоре, в том числе перемещать кубы, поэтому он быстро. По сути, они обманули - обычно приложения WebGL не будут такими.

У Google был разговор, где они объясняли эту технику (они также нереалистично вычисляют движение объекта на GPU): https://www.youtube.com/watch?v=rfQ8rKGTVlg

Ответ 3

OpenGL более гибкий и оптимизирован из-за использования новых версий api. Это правда, если вы говорите, что OpenGL быстрее и эффективнее, но он также зависит от ваших потребностей.

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

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

Чтобы ответить, это не узкое место на языке, а используемая версия api-версии. WebGL основан на OpenGL ES, который имеет некоторые преимущества, но также работает немного медленнее, и у него больше уровней абстракции для обработки кода, чем у чистого OpenGL, и это причина снижения производительности - требуется больше кода.

Если ваш проект не требует веб-решения и не заботится о том, какие устройства поддерживаются, то OpenGL будет лучшим и разумным выбором.

Надеюсь, что это поможет.

Ответ 4

WebGL намного медленнее на том же оборудовании по сравнению с аналогичным OpenGL, из-за высокой задержки при каждом вызове WebGL.

На настольном OpenGL эти накладные расходы, по крайней мере, ограничены, хотя все еще относительно дороги.

Но в таких браузерах, как Chrome, WebGL требует, чтобы мы не только пересекали барьер FFI для доступа к тем вызовам API OpenGL (которые по-прежнему сопряжены с такими же накладными расходами), но у нас также есть расходы на проверки безопасности, чтобы предотвратить захват графического процессора для вычислений.,

Если вы смотрите на что-то вроде glDraw*, которые вызываются на кадр, это означает, что мы говорим о, возможно, (glDraw*) порядке (-ях) меньшего количества вызовов. Все больше причин выбирать что-то вроде инстансинга, где количество вызовов резко сокращается.

Ответ 5

Главное, что вы можете сделать для улучшения производительности WebGL, - это правильно оптимизировать ваши активы. Посмотрите это руководство по двигателям, например.