Производительность WebGL и OpenGL
В течение последнего месяца я возился с WebGL и обнаружил, что, если я создаю и рисую большой буфер вершин, это вызывает низкий FPS. Кто-нибудь знает, будет ли так же, если бы я использовал OpenGL с C ++?
Это узкое место с используемым языком (JavaScript в случае с WebGL) или с графическим процессором?
WebGL примеры как это покажите, что вы можете нарисовать 150 000 кубов, используя один буфер с хорошей производительностью, но что-то еще, я получаю FPS drop Будет ли это то же самое с OpenGL, или он сможет обрабатывать больший буфер?
По сути, я должен принять решение продолжить использование WebGL и попытаться оптимизировать его по коду или — если вы скажете мне, что OpenGL будет работать лучше, и это является узким местом в языковой скорости, переключитесь на C ++ и используйте OpenGL.
Решение
Если у вас есть только один вызов drawArrays, между OpenGL и WebGL не должно быть большой разницы для самого вызова. Однако настройка данных в Javascript может быть намного медленнее, поэтому это действительно зависит от вашей проблемы. Если большая часть ваших данных статична (ландшафт, комнаты), WebGL может хорошо работать для вас. В противном случае настройка данных в JS может быть слишком медленной для вашей цели. Это действительно зависит от вашей проблемы.
постскриптум Если вы включите более подробную информацию о том, что вы пытаетесь сделать, вы, вероятно, получите более подробные / конкретные ответы.
Другие решения
В начале 2000-х годов я написал игру, основанную на плитках, используя старую glVertex() API стиля, который работал идеально гладко. Я недавно начал портировать его на WebGL и glDrawArrays() и теперь на моем современном ПК, который по крайней мере в 10 раз быстрее, он получает ужасную производительность.
Кажется, причина в том, что я притворялся glBegin(GL_QUADS); glVertex()*4; glEnd(); используя glDrawArrays(), С помощью glDrawArrays() нарисовать один многоугольник много много медленнее в WebGL, чем делать то же самое с glVertex() был в C ++.
Я не знаю, почему это так. Может быть, это потому, что JavaScript медлительный. Может быть, это из-за некоторых проблем с переключением контекста в JavaScript. В любом случае я могу сделать только около 500 однополигональных glDrawArray() звонки пока еще получают 60 FPS.
Кажется, что все работают вокруг, делая как можно больше на GPU и делая как можно меньше glDrawArray() звонки за кадр, насколько это возможно Сможете ли вы сделать это, зависит от того, что вы пытаетесь нарисовать. В примере кубов, которые вы связали, они могут сделать все на GPU, в том числе перемещение кубов, поэтому это быстро. По сути, они обманули — как правило, приложения WebGL не будут такими.
Google поговорил, где они объяснили эту технику (они также нереально рассчитывают движение объекта на GPU): https://www.youtube.com/watch?v=rfQ8rKGTVlg
OpenGL является более гибким и более оптимизированным из-за более новых версий используемого API.
Это правда, если вы скажете, что OpenGL работает быстрее и эффективнее, но это также зависит от ваших потребностей.
Если вам нужна одна сетка куба с текстурой, то достаточно webGL. Однако, если вы намереваетесь создавать крупномасштабные проекты с большим количеством вершин, эффектами пост-обработки и различными методами рендеринга (и смещением, параллаксным отображением, на каждую вершину или, возможно, тесселяцией), тогда OpenGL может быть лучшим и более мудрым выбором.
Можно оптимизировать буферы для одного вызова, оптимизировать их обновление, но, конечно, у него есть свои ограничения, и да, OpenGL, скорее всего, будет работать лучше в любом случае.
Чтобы ответить, это не язык узкое место, но апите-версию используемой один.
WebGL основан на OpenGL ES, у которого есть некоторые плюсы, но он работает немного медленнее и имеет больше уровней абстракции для обработки кода, чем чистый OpenGL, и это является причиной снижения производительности — нужно оценивать больше кода.
Если ваш проект не требует веб-решения и не заботится о том, какие устройства поддерживаются, тогда OpenGL будет лучшим и более разумным выбором.
Надеюсь это поможет.
WebGL намного медленнее на том же оборудовании по сравнению с аналогичным OpenGL, из-за высокой задержки при каждом вызове WebGL.
На настольном OpenGL эти издержки, по крайней мере, ограничены, хотя все еще относительно дороги.
Но в таких браузерах, как Chrome, WebGL требует, чтобы мы не только пересекали барьер FFI для доступа к тем вызовам API OpenGL (которые по-прежнему сопряжены с такими же издержками), но и также иметь стоимость проверок безопасности, чтобы предотвратить захват графического процессора для вычислений.
Если вы смотрите на что-то вроде glDraw* Вызовы, которые вызываются на кадр, это означает, что мы говорим о, возможно, порядке (-ях) меньшего количества вызовов. Все больше причин выбирать что-то вроде инстансы, где количество звонков резко сокращается.