Search Unity

Тестирование производительности WebGL

, 15 декабря, 2015

Около года назад мы провели тестирование производительности Unity WebGL для различных браузеров. По этой ссылке доступны полученные нами сравнительные оценки. Прошло достаточно много времени, и мы решили провести повторное испытание, чтобы выявить изменения в производительности.

Одной из основных целей тестирования стала система Windows 10 с новым браузером Edge, поддерживающим по умолчанию подмножество asm.js. Мы также включили в тестирование экспериментальную сборку Unity, обеспечивающую многопоточное исполнение кода с помощью компонента Shared Array Buffers. Чтобы оценить будущий прирост производительности, мы испытывали эту сборку в сочетании с новейшей версией Firefox.

Вы можете попробовать обновленный пакет тестов для оценки производительности по этой ссылке.

Untitled 2

Некоторые изменения методики тестирования по сравнению с прошлым годом:

  • Используется обновленная версия сборки тестов, созданная с помощью Unity 5.3. Вы можете скачать ее здесь и поэкспериментировать сами — локально или на других платформах.
  • Мы убрали из этой версии все графические украшения. Они не несли смысловой нагрузки и лишь увеличивали размер сборки. Благодаря этой чистке стало возможным свободное распространение сборки (см. ссылку выше).
  • Мы пропустили тест «Mandelbrot GPU». Он не подходил для сравнительной оценки производительности различных браузеров, так как загружал только графический процессор, и из-за этого смазывались общие результаты тестирования.
  • Также мы опустили сравнение с автономной нативной сборкой. Мы решили, что результаты такого сравнения недостаточно информативны, так как мы используем различный код для разных платформ с использованием несовпадающих настроек (например, различные реализации обработчика сценариев и наборы шейдеров).
  • Версия EdgeHTML 12 (Edge 20.10240.16384.0), использованная при тестировании, не подключает asm.js по умолчанию. На данный момент доступна версия 13, в которой это исправлено, но для испытаний нам пришлось подключать поддержку asm.js вручную.

Далее приведены результаты сравнительного тестирования различных браузеров. Для тестирования использовался компьютер на основе процессора Intel i7 с частотой 3,3 ГГц, с видеокартой NVidia GTX 960 и ОС Windows 10. Тест экспериментальной версии Unity в сочетании с «ночной» сборкой Firefox выделен серым цветом.:

Screen Shot 2015-11-30 at 1.51.33 PM

Также мы провели несколько тестов на ноутбуке производства Apple (Retina MacBook Pro 15″ с процессором i7 2,6 ГГц и ОС Mac OS X), чтобы получить сравнительные результаты для Safari:

Screen Shot 2015-11-10 at 11.12.52 AM

Далее приведены детализированные результаты каждого теста, проведенного на Windows. За единицу принят результат теста для 32-битной версии Firefox 41:

Screen Shot 2015-11-30 at 1.52.40 PM

Далее — результаты для OS X (результат для Firefox также принят за единицу):

Screen Shot 2015-11-10 at 10.00.57 AM

Приведем для сравнения результат прошлогоднего тестирования. Тогда также использовался ноутбук Retina MacBook Pro 15″ с процессором i7 2,6 ГГц и ОС Mac OS X:

Screen Shot 2015-11-10 at 10.22.29 AM

Наконец, последний график показывает, сколько времени тратится на запуск Unity при использовании различных браузеров. Каждая строка отображает, сколько времени (в секундах) проходит между открытием тестового проекта и завершением рендеринга первого кадра при загрузке с локального диска. Для каждой версии Firefox приведены две строки, представляющие время первого («холодного») запуска с кэшированием результатов сборки asm.js, и последующих («горячих») запусков с пропуском кэширования, которые происходят быстрее:

Screen Shot 2015-11-30 at 1.35.35 PM

Некоторые факты:

  • Наилучших результатов в большинстве тестов из всех публично доступных браузеров достигает 64-битная версия Firefox 42. 32-битная версия заметно уступает в скорости.
  • Edge занимает второе место после Firefox, и в некоторых тестах обходит 32-битную версию. В тестах на производительность рендеринга с использованием библиотеки WebGL Edge превосходит все остальные браузеры.
  • Safari сравним по производительности с Chrome. Прошлогодние тесты показывали значительное превосходство Chrome.
  • Internet Explorer 11 твердо занимает последнее место.
  • Экспериментальная версия Unity с использованием Shared Array Buffers значительно увеличивает производительность, иногда — в несколько раз. Это дает некоторые представления о том, на какие показатели производительности следует ориентироваться в будущем.
  • Производительность Firefox на OS X выросла в среднем на 18% по сравнению с прошлогодними результатами. Отчасти это происходит благодаря оптимизации версии Firefox 41 по сравнению с 32, но главным образом ускорение обязано улучшениям в Unity и в компиляторе emscripten. Производительность на Windows выросла заметнее, так как 64-битные версии Firefox для этой ОС появились недавно, а для OS X существовали уже долгое время и уже использовались в прошлогоднем тестировании.
  • Большинство браузеров загружает тестовый проект за 5–7 с. Firefox способен сократить это время до 1,5–2 с при выполнении горячей загрузки с заранее кэшированной сборкой asm.js.

38 replies on “Тестирование производительности WebGL”

I can’t run the benchmark in Internet Explorer 11 ( Inori version ), the WebGL player return an Out of memory error.

On Linux, without proprietary drivers and running Firefox, the benchmark «runs», I mean, the whole screen is messed up, but at least it runs. With proprietary drivers on, I got a wonderfull pinkish bubblegum screen, and nothing works.

Sorry about double post, but the WebGL bench just started in Internet Explorer 11 (Inori version), it seems that the Out of Memory is pretty random…

My scores:

Mandelbrot Script: 15 169
Instantiate & Destroy : 10 806
CryptoHast Script: 46 588
Animation & Skinning: 34
Asteroid Field: 2 148
Particles: 13 010
Physics Meshes: 29
Physics Cubes: 38
Physics Spheres: 51
2D Physics Spheres: 103
2D Physics Boxes: 72
AI Agents: 250

Overall Score: 11 476

Glad to see some benchmarks around this. I was especially surprised to see how the different browsers performed on my own hardware. I definitely get different results on Windows 10. I actually get Edge>Firefox>Chrome. Not entirely sure why though.

As far as performance, its getting to «good enough» for many things. I won’t be trying to push AAA content directly in the browser, but for things like social games and apps — its definitely pretty close to where I don’t care so much about the benchmarks anymore.

How about mobile browser?

i tried a small project with just a ugui scroll view, only have 15 fps in release WebGL in iphone 6s safari.

Looking forward to see better performance in mobile browser :D

My results on Firefox 43 64 bits, Windows 8.1 64bits, NVIDIA GTX 780 (358.87):

With Angle (D3D11?) : 67794

With «webgl.disable-angle» : 68138

Seeing your results, either something went wrong in 43 or I’ve done something wrong in my Fox config.

Fedora Linux 23
AMD A8-6600K APU
Firefox 42
54965 overall

The results published in the blog are basically useless, because of being normalized. Since they don’t give the numbers in a way that I can use to compare my own results to the published results, it is all meaningless. Even after you run it yourself, you get no comparative information, and the types of things tested are very different from each other. Presumably there is some sort of typical reason common to published benchmarks why this would be concealed. ;)

OSX 10.11
Firefox 43.0

iMac 24GB Ram, 4GB 780m.

During the Particles benchmark, firefox throws up a dialog «Out of memory. If you are the developer of this content, try allocating more memory to your WebGL build in the WebGL player settings.»

I would also have liked to see results from linux in comparison. I guess we would still see some funny results heading in unknown direction, but knowing is always better than guessing :)

Sad that Firefox 43 and 46 was not tested.
Also It could be a very useful idea to bench also on Linux. The gpu drivers are really different.

And what about the layout engine of the future ? Servo + webrender +browser.html

I took a look at webgl export in 5.3 .. safe to say i won’t be bothering with it, the output scene lighting was completely off from the web standalone, and performance of the scene even after changing settings to be as low as possible was just not worth it.

And the webgl compile time turned my pc into barely useable brick for way too long, no idea who’s bright idea it was to set all compiling processes thread priority onto anything but ‘below normal’ kinda stupid given there is no setting in unity to set the thread priority before it starts, probably the same programmer who set the lighting building processes to the same.

oh and to top it off the webgl version left a 70mb opengl.js with the total size for webgl export being 82mb. Unity provides no way of seeing what the hell its exported out. For comparison the web standalone export was 3mb.

Maybe in 2017 webgl might be worth checking out again right now its bleh, ofc UE current track of releasing decent updates with actual built in engine features as opposed go find and buy such improvements at the asset store might have me switching to that in 2016 instead.

Firefox 43 64 bit / Windows 10 64 / i3 530@4 GHz+8GB RAM / GeForce 750 Ti

My results:

Native WegGL+WebGL2 — 64590
Native WegGL — 61865
Angle D3D11 — 54857
Angle — 50575

Great work.

Will Shared Array Buffers be mapped to C# threads so our own multi-threaded code can take advantage of them via IL2CPP?

Any news on progress with SIMD, WebGL 2.0, WebVR and WebAssemby.

I disagree with the decision to omit standalone results from the comparison.

It’s important to understand the performance hit you’re going to take by choosing WebGL over standalone. Which areas are significantly weaker? Which are nearly comparable?

Further, performance is increasing over time on standalone as well and it’s valuable to compare the changes on each platform. If performance increases on standalone are outpacing those of WebGL, that means the gap between the platforms is increasing even in the face of the WebGL improvements and will affect the decision to leverage the platform. Likewise, if the gap is closing, that makes a stronger case for WebGL.

I have to wonder if the comparison was omitted because it potentially paints WebGL in a more negative light, but imho the comparison is crucial to making an informed decision. Sure, we can do the benchmarks ourselves, but why omit the information when you’re already publishing results publicly?

Awesome, I was in the middle of writing a presentation on Unity’s WebGL benchmarks when you updated this today.

Thanks for keeping us in the loop, looking forward to seeing how browsers improve perf over time.

Great to see more info on WebGL builds.

What about mobile ( other WebGL tech seem to work ok, eg Blend4Web, PlayCanvas etc ), would be cool to have WebGL as a potential option for smaller games across desktop and mobile.

Also would be cool to have report on reduced file size ( if any ), of say a single cube, to get an idea of the overhead pre adding assets. Maybe build times as well.

Keep up the great work in this area!
Mal

Comments are closed.