Производительность 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, - это правильно оптимизировать ваши активы. Посмотрите это руководство по двигателям, например.