Quoting  https://crbug.com/753867#c4 

>On Windows, the renderer process with runaway allocations terminates at around 3gb of Private Working Set (the Windows Job sandbox is capped at 4gb).

A better quote from  https://crbug.com/416284#c5  by wfh@chromium.org:

>Yes this is working by design.  This is a security limitation placed on the sandboxed process using a Windows Job object.  We limit to 4Gb because certain types of attacks rely on being able to allocate > 4Gb of memory.

jschuh@, wfh@: this is related to  Issue 675642 , where we raised the limit of the GPU process's sandbox to larger values.

To support larger customers' apps like this one (their app is much more complex than the simple test case attached here), would it be possible to raise the sandbox limit on Windows to something like 8 GB?

The test case loads on macOS -- though it brings my laptop to its knees. More realistic workloads are probably possible which would render OK but still run out of memory in the Windows sandbox.

Hello,

Any news on this ? We have more and more customers in Automotive / Aero /
Energy / shipbuilding  willing to visualize huge 3D datasets ( Toyota,
Airbus, Boeing, HHI, Mayerwerft).

Even with advanced out of core and compression algorithms, this 4 Gb limit
is very restrictive for such scenarii.

We will discuss lifting this limit with security team.

That said, you are reaching a limit of CPU memory. On Windows, we emulate OpenGL ES semantic on top of D3D through ANGLE, for which we have to keep a staging copy of texture data in the CPU as well as uploading them to GPU. This is due to the way how textures are created in D3D.

I suspect this is the root cause of you reaching 4gb CPU memory limit.

If you upgrade to WebGL 2.0, and use TexStorage{2|3}D instead of TexImage{2|3}D, then ANGLE no longer needs to keep a staging copy of texture data in the CPU.

Ken, maybe we should consider exposing tex_storage extension to WebGL 1.0? As WebGL 2.0 support on Windows is still lagging behind.

Hello, no, unfortunately this is not due to texture footprint, as there are
almost inexistant in CAD models :-)

The high memory usage is due to :

1/ the data structure (Scene Graph) wich can be extremely complex and which
is required in a lot of scenarii.
2/ the geometry (meshes) which is required for some operators and display
modes

So does this happen on Intel? Because all these complexity should only affect GPU memory, not CPU, unless on Intel, these two are the same.

The problem happens in the renderer process, that hosts V8, not in the GPU
process. So far, we have no problem with the GPU process.

Ah, I got confused by comment #3. Sorry about the noise then.

No problem ;-)

After internal discussion it's been resolved to do a 50/50 A/B experiment where for 64-bit clients the renderer process limit is raised to 8 GB. That will help inform any risks of increasing memory consumption or crash rates across the board with such an increase.

wfh@ can you help set this up or do we need to find someone from the GPU team to do so?