Hi, I’ve recently noticed my project performing quite badly on my macbook. I think it started after I most recently updated the OS (to the current version, big sur 11.6). Of course it’s impossible to downgrade and check.
I’m wondering if anyone else has seen similar, or has any ideas for how to address it?
Specifics: the scene I’m testing is static, with ~200 meshes, ~30 materials, and roughly 200K active indices and vertices. Here is what it looks like when profiled on current Chrome, current macOS:
As you can see the GPU is the bottleneck, while the CPU is largely idle - which is surprising, as until now I believe my project was always CPU-bound.
(Actually, pretty much every Babylon project I’ve ever seen has been CPU-bound, so I’m not really even sure what might cause a scene to become GPU-bound in the first place.)
Yup I have to admit I hate Safari … (it makes me feel better to say it loud)
Their latest release has introduced new settings and webgl2 support. In theory it should be quite faster but I think you might try to play with Develop → Experimental Features → GPU Process: WebGL and other GPU related setups. Would be great if you could let us know your findings ?
Here it seems like you are running in emulation mode or smthg and you would render in software mode
I am so focused on Safari issue I have seen Mac and automatically thought that…
This is really surprising indeed something seems completely wrong… Could you share a repro with both a version of babylon which was ok andtge broken one ? I d like to find it fast.
I wish we could be GPU bound for real in javascript
As I said, I’m seeing the same issue in Babylon 5 and 4.2, so I can’t easily find a non-reproducing babylon version. That’s why I suspect it might have been due to the MacOS update.
My current scene isn’t shareable, but I’ll try to make a public one that reproduces the issue…
Open page and wait 5-10 seconds for world to be created
Open chrome devtools, Performance tab, and profile for a few seconds
That should reproduce the GPU-bound behavior. Note that I’m testing this on an old macbook - If you’re on a beefy machine and you need to make the scene heavier to reproduce, open the JS console and run this:
// pass in a value of 8 or higher to make the world heavier
noa.world.setAddRemoveDistance(8)
Note: the scene is added to the window object, so to poke around you can just to scene.getTotalVertices() in the JS console.
I am still trying to investigate but unfortunately I do not repro on my mac or other platform, it does not make much sense. @Cedric could you try to repro ?
I wonder if you have a special browser setting in some ways ?
Hmm. Are you not seeing a slowdown at all? The framerate (top number at the upper right) should start at 60fps, but then gradually slow down as the world fills up with data (this takes 10-20 seconds). Are you seeing a constant 60fps, or is it slowing down while still being CPU-bound?
If you’re seeing constant 60fps, the scene may not be heavy enough to stress your machine. (I’m using a mid-2014 macbook, Intel gpu 1.5GB, so you’re probably on much faster hardware). If that’s the case just increase the world size with the JS I posted.
For me the repro site performs similarly in Firefox/Safari, so I don’t think it’s anything browser specific. (Though of course I don’t have detailed profiles for other browsers.)
Constant 60fps, even after running noa.world.setAddRemoveDistance(8) command and noa.world.setAddRemoveDistance(16). With noa.world.setAddRemoveDistance(32), framerate is more volatile between 35 and 55.
Do you have dynamic (per frame) creation of mesh/texture ? I didn’t check the code but it looks like the more distance, the more dynamic creation and the more the GC tries to collect them.
It’s a voxel engine (like minecraft), so it dynamically creates meshes and textures until the world is fully meshed. That function sets the upper limit on the world size, so if you call it with 32 then it will keep creating meshes until there are 32 chunks of terrain in each direction.
The scene object is in global scope, so you can do scene.getTotalVertices() or the like. When the total vertex count stops changing, then the engine is done creating meshes/materials.
This would mean that you are vertex bound for some reasons
Do you have an old version of the project before 4.2 to compare in case we introduced a regression in the vertex shader ? or did the perf only change after an upgrade on the mac ?
Sorry for all the questions, just trying to narrow the issue down
The issue didn’t start when upgrading BJS, it’s either due to some change I made in my project, or to the macOS update. I think it’s the latter, as I see the issue in older project versions, but of course I can’t bisect against the OS update.
That said, I wouldn’t think it’s purely the vertex count, as the issue is very noticeable in my real project even with relatively few vertices (details in the top post). But the real project is much more complicated - dynamic meshes, multimaterials, many thininstances, etc., so it’s hard to isolate anything.
is it also happening if you reduce the size of the window ??? (to understand if you d be fragment bound)