Performance gap with PlayCanvas on MacOS

[xiasun]

I have gone through several web implementations including this Three.js one, the Babylon embedded one, and Gsplat.js. All of these share similar performance on windows PC with the same data. However, the PlayCanvas one is significantly faster on my MacOS. With 5 million splats, the framerate is about 3 to 4 times higher. I wonder if you have any suggestions for this?

My major work are based on Babylon so I start a thread there to describe what I have done so far. But I thought this problem might also be a common issue with this Three.js impls.

I would appreciate any suggestions you might have for me.

[mkkellogg]

Do you have a specific scene you could share that exhibits the issue? Maybe i can use that to start debugging. Also, could you share your code for initializing the Viewer?

[xiasun]

I eventually found out the huge performance gap between SuperSplat (PlayCanvas) and other WebGL implementations was a bug of chromium on MacOS, that render a same scene with same params to texture was FASTER that render to back buffer directly. It has nothing to do with GS itself. Thanks!

[d0rianb]

I have looked in PlayCanvas source code, and specifically this pull request which seems to have well improved their splat rendering performances.
It looks like they are using Morton encoding to sort their splat, and that they are submitting it to the GPU directly via a Texture, instead of a FloatArray / IntBuffer.
On large scene (>1M splat), it seems to make a difference, at least on my Macbook.

[mkkellogg]

In the current code, if you don't load scene progressively, my viewer makes similar optimizations: It re-orders the splats according to spatial proximity. Additionally my viewer has always stored splat data in textures 😄

[d0rianb]

Ok thanks, I didn't noticed that disabling progressive loading would have such an impact on performance improvement :)
One more thing, why is the sorting only partially done on the GPU ? Is there a limitation that prevents this, or is it something left to do ?

[mkkellogg]

Well by default the sorting is done completely on the CPU. When gpuAcceleratedSort is set to true, you're right about the sort only being partially done on the GPU (just the splat distances are computed on the GPU). This is because the viewer is based on WebGL, and there's not a good way to do a parallelized sort on the GPU with WebGL. It is possible to pre-compute the splat distances are on the GPU though, because that operation is easily parallelizable.

[xiasun]

@d0rianb The motion order gave me a small improvement (fps 18 to 23). If you're on an Apple Silicon Mac, I guess there would be no more big problem then. On Intel Mac, there will be an additional RT issue which has a 4 times performance gap.