webgl unity
When we port Unity to new platforms, it is always an important question to find out how well it performs on that platform – and to see what we can do to make it perform as fast as possible.
当我们将Unity移植到新平台时,找出它在该平台上的性能如何–并查看如何使它尽可能快地运行始终是一个重要的问题。
One exciting new platform we are currently working to support is WebGL. WebGL is unique when it comes to performance: all code needs to be cross-compiled to JavaScript; some common performance-enhancing techniques, like multi-threading and SIMD, are not available yet; and we are relying on a completely new scripting runtime, IL2Cpp, to run user script code. So we need to find out: Will it be fast enough to play games? How will different browsers and hardware compare? What build settings will produce the fastest results?
我们目前正在努力支持的一个令人兴奋的新平台是WebGL。 WebGL在性能方面是独一无二的:所有代码都需要交叉编译为JavaScript; 一些通用的性能增强技术(例如多线程和SIMD)尚不可用; 而且我们依靠全新的脚本运行时IL2Cpp来运行用户脚本代码。 因此,我们需要找出答案:玩游戏是否足够快? 不同的浏览器和硬件如何比较? 哪些构建设置将产生最快的结果?
These are the questions we have asked ourselves, and we have frequently been asked by our users as well as by suppliers of WebGL implementations. The most obvious approach is to run existing Unity content in WebGL and measure the frame rates. We found that, for most of the content we’ve tried, frame rates are at least 50% of native builds (depending on many factors, such as the browser being used). You can try two demos of games exported to WebGL here. However, we would like to get precise and reliable numbers. Which areas are particularly slow in WebGL? Which are fast? How do different implementations compare, exactly?
这些是我们问自己的问题,我们的用户以及WebGL实现的供应商经常问我们。 最明显的方法是在WebGL中运行现有的Unity内容并测量帧速率。 我们发现,对于我们尝试过的大多数内容,帧速率至少是本机版本的50%(取决于许多因素,例如所使用的浏览器)。 您可以在此处尝试导出到WebGL的两个游戏演示。 但是,我们希望获得准确可靠的数字。 WebGL中哪些区域特别慢? 哪个快? 确切地说,不同的实现如何比较?
To find out, we have created Unity Benchmarks, a suite of benchmark tests written in Unity. The benchmarks stress different areas of the engine and produce easily-comparable numbers on performance. Click here to try Unity Benchmarks in WebGL in your browser! (Note that some WebGL implementations on windows may get incorrectly high results for the Mandelbrot GPU benchmark, as they won’t render the shader correctly. We are investigating the issue and looking for a fix.)
为了找出答案,我们创建了Unity Benchmarks,这是一组用Unity编写的基准测试。 基准测试对发动机的不同区域施加压力,并产生易于比较的性能数字。 单击此处,在浏览器中尝试WebGL中的Unity基准! (请注意,Windows上的某些WebGL实施对于Mandelbrot GPU基准测试可能会获得不正确的高结果,因为它们无法正确渲染着色器。我们正在研究此问题并寻求修复。)
Unity Benchmarks has different tests stressing 3D physics, 2D physics, particles, navigation, animation & skinning, object instantiation, scripting, draw calls and GPU pixel throughput. Each benchmark will count how many iterations of a given task Unity can perform in a fixed amount of time. For the reported numbers, higher is always better.
Unity Benchmarks进行了不同的测试,这些测试强调3D物理,2D物理,粒子,导航,动画和蒙皮,对象实例化,脚本,绘图调用和GPU像素吞吐量。 每个基准测试都会计算Unity在固定的时间内可以执行给定任务多少次迭代。 对于报告的数字,越高越好。
If you run all of the benchmarks, it will also show an Overall Score value. This score is calculated as a weighted sum of all the individual test results. Since the different benchmarks have very different result scales, they each carry different weights in the overall score. The weights are calibrated to produce similar result scales on my development machine running in WebGL. But that is somewhat arbitrary, so, when comparing results, the individual scores are much more meaningful than the Overall Score!
如果您运行所有基准,它也会显示“总分”值。 该分数是所有单个测试结果的加权总和。 由于不同的基准具有非常不同的结果量表,因此它们在总分中的权重各不相同。 在WebGL上运行的开发机器上,对权重进行了校准以产生相似的结果比例。 但这有点武断,因此,在比较结果时,单个分数比总体分数更有意义!
So, after all the explanations, here are some results (all benchmarks are run on a 15” Retina MacBook Pro 2.6 GHz i7 running OS X 10.10):
因此,经过所有解释,下面是一些结果(所有基准测试均在运行OS X 10.10的15英寸Retina MacBook Pro 2.6 GHz i7上运行):
The scores have been scaled so that Firefox = 1.0, to fit onto a single chart. Higher is better.
分数已按比例缩放,以使Firefox = 1.0,以适合单个图表。 越高越好。
Some observations:
一些观察:
-
In almost all benchmarks, Firefox with asm.js is faster than both Chrome and Safari in almost all benchmarks, and is currently the best browser to run Unity WebGL content. We hope to see asm.js support showing up in other browsers in the future as well, however – see here for some interesting comments on this subject.
在几乎所有基准测试中,带有asm.js的Firefox在几乎所有基准测试中均比Chrome和Safari都快,并且是目前运行Unity WebGL内容的最佳浏览器。 我们希望将来也会在其他浏览器中看到对asm.js的支持,但是–有关此主题的一些有趣评论, 请参见此处 。
-
When you are mostly GPU-bound, you can expect WebGL to perform very similar to native code.
当您主要受GPU限制时,您可以期望WebGL的执行与本地代码非常相似。
-
In some areas, WebGL will actually outperform native code significantly. This is the case for tests which rely a lot on script performance (Mandelbrot and CryptoHash, which both implement their algorithms in C#), as IL2Cpp can produce more optimized code (expect to read more about this in another blog post soon).
在某些方面,WebGL实际上将大大优于本机代码。 这种情况在很大程度上取决于脚本性能的测试中(Mandelbrot和CryptoHash都使用C#实现其算法),因为IL2Cpp可以生成更多优化的代码(希望很快在另一篇博客文章中了解更多信息)。
-
Native code can still be several times faster than WebGL for areas heavily optimized to use multi-threading and/or SIMD, such as the 3D physics tests (PhysX 3.3 in Unity 5.0 is now fully multi-threaded). Compared to that, 2D physics is very close to parity when comparing Firefox to Native (Box2D is not multi-threaded). We hope that the future will bring SIMD and multi-threading extensions to JavaScript, at which point this may change.
对于3D物理测试(Unity 5.0中的PhysX 3.3现在是完全多线程的)进行了充分优化以使用多线程和/或SIMD的领域,本机代码仍可以比WebGL快几倍。 与此相比,在将Firefox与本机进行比较时(Box2D不是多线程的),2D物理非常接近于奇偶校验。 我们希望将来会为JavaScript带来SIMD和多线程扩展,这可能会有所改变。
The most important takeaway is, while there are still areas where WebGL is significantly slower than native code, overall you can get expect very decent performance already, and this can only get better in the future. I hope that these benchmarks may help anyone looking to optimize performance of their JS engines and WebGL implementations to run Unity content as fast as possible.
最重要的要点是,尽管在某些地方WebGL比本地代码要慢得多,但总体而言,您已经可以预期到非常不错的性能,而且将来只会变得更好。 我希望这些基准可以帮助希望优化其JS引擎和WebGL实现的性能的任何人,以尽可能快地运行Unity内容。
翻译自: https://blogs.unity3d.com/2014/10/07/benchmarking-unity-performance-in-webgl/
webgl unity