Chrome Aw Snap, Firefox out of memory when using cesium to render city buildings and shapes

[ale...@gmail.com]

I'm using Cesium in conjunction with OSM (Open Street Maps) data to render sections of cities, including buildings as solid shapes and semi-opaque objects to represent other map objects.

I have a decent graphics card (GeForce GTX 750) with 4GB Total graphics memory and 1GB dedicated video memory. My GeForce drivers are up to data.

If I use a fetch radius of less than 1500 meters Cesium works great on both Chrome and Firefox. If I increase the radius to 2500 meters, Chrome fails with "Aw Snap" and firefox fails with "Out Of Memory"

I don't expect to be able to add all the buildings indefinitely but our demo would be much more effective if we could use about 2500 meter radius.

I don't need a general purpose fix for this. If there is a Chrome command line start up setting I can use to allow my Cesium Chrome instance access to more GPU memory, that would be a great interim solution.

Does anyone have any suggestions what I could do to give Cesium access to more memory?

Thanks,
Alec.

[Matthew Amato]

First, be sure you are using the 64bit version of Chrome. 32bit apps only address up to 4GB of RAM (and depending on OS it can be lower).  Chrome has artificial per-tab memory limits for the JavaScript engine of around 1GB on 32 bit and 2GB on 64 bit.  As you can see, just running 64 bit will get you more memory.

Assuming that's still not enough, you can change the artificial limit by passing the --max-old-space-size to V8.  This specifies the limit in megabytes.  For example, if you want to raise the limit to 16GB you would run

chrome.exe --js-flags="--max-old-space-size=16384"

Don't set the value to higher than the amount of RAM on your machine.  You also have to make sure chrome is not running in any capacity when you launch or else the command won't take.  You can confirm this by checking the special chrome://version page, which lists command line arguments.

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jsal11]

Even with current Cesium & Chrome version (Windows 10 64 bit), this situation seems to occur. Chrome crashes with "Aw snap!" about once in 5 minutes when testing with 5 Gb 3d-tileset.

I haven't been able to reproduce this crash, when I add this: --js-flags="--max-old-space-size=4000".

Is there some setting I could tweak on Cesium side to make default chrome work without crashing?

[mage...@gmail.com]

Same problem here, Chrome crashes after a few minutes. I'm receiving information to change model's position every 4 seconds and I have also some polygons in the globe. The problem is the size of the json? Is there a way to stop the crashing without altering the original data?

[Gabby Getz]

Can you be more specific about what you're doing? Is this a 3D Tileset? How big is the json? Is it possible to provide a code sample?

Thanks,

Gabby

[jsal11]

If you have about 4-5 gigabytes of 3d tiles data, the "aw snap" error reproduces at almost 100% certainty. The might be something wrong with the webgl memory management.. I have never seen this issue with smaller tilesets though.

--
You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/BcbyELEXFHI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cesium-dev+unsubscribe@googlegroups.com.

[pink6...@gmail.com]

On Saturday, September 2, 2017 at 10:44:26 AM UTC+2, jsal11 wrote:
> If you have about 4-5 gigabytes of 3d tiles data, the "aw snap" error reproduces at almost 100% certainty. The might be something wrong with the webgl memory management.. I have never seen this issue with smaller tilesets though.
>
>
> On Fri, Sep 1, 2017 at 10:46 PM, Gabby Getz <gget...@gmail.com> wrote:
>
> Can you be more specific about what you're doing? Is this a 3D Tileset? How big is the json? Is it possible to provide a code sample?
>
>
> Thanks,
> Gabby
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
>
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/BcbyELEXFHI/unsubscribe.
>

> To unsubscribe from this group and all its topics, send an email to cesium-dev+...@googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

I'm also facing the same problem, I have about 90.000 facades of 12K buildings in geojosn.
Chrome keeps on crashing and Firefox, in case it works, will take forever otherwise will also crash.
how can I ease the data into the browser?

[Sean Lilley]

I don't have a good solution for GeoJson since it will try to load everything regardless of GPU memory, but for 3D Tiles you may want to increase tileset.maximumScreenSpaceError to render less tiles overall or decrease tileset.maximumMemoryUsage so less tiles are held onto in the cache.

[jsal11]

I have now experienced this on iphone iOS 11 safari browser too. Even with way smaller models, like 100mb of ,3dbm data.

I think this should be somehow addressed really.. is it a webgl problem that we cannot really know how much data we can push to GPU mem before crashing or what is going on here? 

I don't think it should be accepted that Cesium just "hard crashes" randomly with big models.. It would be even better solution to stop loading any more tiles and inform user with message box?

On Tuesday, July 21, 2015 at 5:36:05 AM UTC+3, ale...@gmail.com wrote:

[Sean Lilley]

That is the main problem, it isn't possible for us to query the amount of GPU memory a system has. I am surprised though that 100mb of b3dm tiles causes a crash - does the tileset have textures? Those will take up a lot more GPU memory in their uncompressed state compared to jpeg. GPU-compressed texture formats are supported in Cesium, just not that well documented so let me know if that's of interest to you. If your tileset doesn't have textures just ignore everything I just said.

The suggestions in my post above are still the best options at the moment unfortunately. At the very least maybe the Cesium API should have a maximumMemoryUsage option.

[jsal11]

One observation though: setting the --js-flags="--max-old-space-size=4000" prevents this issue from reproducing. So maybe it is not the opengl gpu mem issue after all? I have set the maximumMemUsage parameter to 800mb in my tests.

--

You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/BcbyELEXFHI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to cesium-dev+unsubscribe@googlegroups.com.

[Sean Lilley]

Oh interesting, there is at least one other case where that is happening: https://github.com/AnalyticalGraphicsInc/cesium/issues/3453.

If you are able to post a screenshot of the Logging panel with the 3D Tiles Inspector, that would be very helpful.

To unsubscribe from this group and all its topics, send an email to cesium-dev+...@googlegroups.com.

[jsal11]

Again, I was investigating more on this.

My tileset is 1GB of binary b3dm tiles (gzipped) and about 2500 tiles.

Couple of observations:

* Newest firefox does not crash this way, Windows taskmanager shows firefox taking 12 GB of memory and still not crashing.

* Chrome chrashes with Aw Snap error around 6GB of allocation

* Chrome in Incognito mode works fine! :o It shows 11GB of memory allocation in task manager and everything working fine!

* If I take a heap snapshot, Javascript has not allocated more than 500 Mb or so.. Heap snapshot does not really seem to show the origins of this memory behaviour.. or then I cannot use it!

[jsal11]

Here is the inspector statictics when it happens to work, and does not crash:

[Sean Lilley]

Wow yeah that is a lot of geometry. How large is the tileset before it's gzipped? I would not expect the geometry memory to exceed that.

[jsal11]

It is around 8Gb.. but remember: the situation described in the inspector view below works -fine- in firefox and chrome incognito mode! Which is quite mysterious to me :)

I think webgl/opengl driver is doing good job here to take care of keeping some geometry in RAM and only necessary amount in GPU mem.

I noticed this: If I made one b3dm-chunk 2x bigger in the tileset (=> so I am having 1000 tiles then), Chrome seems to stop the "Aw snap!" So at the moment it looks like this (also) has something to do with large number of tiles loaded simultaneously..