SO here is the situation: Chrome needs to initialize every texture before it's used if the texture is created with null data.  For 3D textures, we didn't optimize the initialization, so when you try to upload the first slice, we initialize the entire texture first.  I think this is causing some out-of-mem problem - I need to confirm this with further debugging.

We definitely could/should optimize the slice by slice upload code path though, avoiding triggering full texture initialization.

This was my assumption as well. The thing is that I can't reliably create a 1 GB Float32Array to pass to texImage3D in the first place. It fails with with 'RangeError: Array buffer allocation failed' most of the time.

I think the common pattern of creating a large 3D texture is to create it with null data and then upload slice by slice.  Chrome should optimize such use case. I'll put it on my TODO list if no one else beats me to it.

Should we start by changing how Chrome initializes 3D textures? If they're over a certain threshold, initialize them slice-by-slice with TexSubImage3D?

This is a 64-bit build of Chrome, so it should be possible for the GPU process to allocate a 1 GB array.

Sorry for the delay. Finally I spent some time looking into this issue.

I was able to set the slice to 2000 and it still works fine, but when I set it to 2048 or 2046 (2048 is MAX_3D_TEXTURE_SIZE on my Linux NVidia), I was able to reproduce the context lost.

Looking deeper, it's not really running out of vram, but rather, running out of CPU ram. Also, it's not from Chrome (I realized I already optimized initializing a large texture by doing it trunk by trunk). It's from NVidia when calling glTexImage3D(R32F, RED, FLOAT, width=512, height=512, depth=2046), it tried to allocate a 2046M CPU ram and failed.

Chrome register its own handler so it crashes the process.  If I disable that, then we get an OUT_OF_MEMORY GL error from NVidia driver and again, Chrome crashed GPU process on that.

I suspect Chrome might use a bit more CPU ram than Firefox, but I suspect when you run 4000 slices on Firefox, they didn't successfully set up the 3D texture. They simply didn't crash.  If you add a gl.getError() call right after gl.texImage3D() in Firefox, you probably get a OUT_OF_MEMORY GL error.

Let me assign this to our NVidia colleague and see if they can optimize glTexImage3D calls and not requesting a huge CPU ram on that.

Olli, this crash is easy to reproduce using Chrome on Linux NVidia. Simply increase the slice count and at certain point, this crash happens.  Note that it's from a TexImage3D() call with nullptr data pointer. Can you bring this to the driver team and ask if they can optimize this? Otherwise we will not be able to create large 3D textures on NVidia.

It has been a while and I haven't got time to work on this since then. 

T know the CPU ram limitation is very low on Chrome for Linux (~1.8GB), but I was discarding the data as soon as it was uploaded into VRAM,and, IIRC, the amount of CPU RAM reported in the Chrome task manager was only about 400 MB. But it might be the issue since Firefox JS memory ceiling is virtually unlimited (I can allocate and use ~30 GB easily).

In FF, I was rendering oblique slices of a medical volume so I'm fairly confident I would have noticed any unsuccessful setup of the 3D texture.

Chrome was hitting this limit on my Linux: https://cs.chromium.org/chromium/src/third_party/tcmalloc/chromium/src/tcmalloc.cc?l=306&rcl=8811aed463ee87b0302ff8a80a730ebd86dee515

which is max_int - 4k = 2G - 4k.

I have no clue why on your side you can only do 700 slice though.  That seems to be way under Chrome's limit.

+jschuh

All in all, I still think NVidia should optimize the driver code and avoid allocating 2G CPU ram (could be larger if we try to create a larger 3D texture).

It has been 3 months, maybe something changed since in the driver or in
chrome. I will investigate a bit next week and report back.

Reducing CPU RAM usage certainly​ can't hurt. Although, why would it not
shot up in chrome task manager and why would it work in Firefox?

Thank you for taking tbe time to look at this. I really appreciate.

> Although, why would it not shot up in chrome task manager

Probably because the allocation is failing, and it's crashing before the memory usage increases.

> and why would it work in Firefox?

The 2GB limit is Chrome-specific (it's a patch to the copy of tcmalloc we have in chrome).

I have been toying with the supplied 'index.html' again and on windows I can allocate up to 2048 slices. At that point, the  additional VRAM usage is about 2.3 GB.Meanwhile, the Chrome task manager reports 17 MB of memory usage for this tab and the windows task manager reveal no chrome process using more that couple hundreds MB. 

On Linux (Linux 4.10.10, NVIDIA 378.13, Xorg 1.19.3, Chrome 57.0.2987.133 (64-bit)), I start to get context lost at about 900 slices with only ~1 GB of VRAM used. I get the errors below on the console.

As a side note, using [0] suggest that Firefox's WebGL 2 implementation supports a 'Max 3D Texture Size' of up to 16384 while Chrome is limited 2048.

Unfortunately, the minimum working example provided does not appear to produce the desired effect in Firefox.
Everything looks fine, but there is no significant memory consumption increase reported in nvidia-smi, maybe it's lazily allocated? The example only writes the first slice.
However,I'm fairly sure I could load about 4000 slices and render arbitrary projections with another prototype.

Hope this helps a bit..

[0] https://browserleaks.com/webgl

[21564:21598:0417/205530.572474:ERROR:service_manager.cc(477)] InterfaceProviderSpec prevented connection from: content_utility to: content_browser
[21564:21678:0417/205530.638945:ERROR:object_proxy.cc(583)] Failed to call method: org.freedesktop.NetworkManager.GetDevices: object_path= /org/freedesktop/NetworkManager: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files
[21564:21678:0417/205530.638956:ERROR:networking_private_linux.cc(720)] Failed to enumerate network devices
tcmalloc: large alloc 1572868096 bytes == 0x1c3d13e48000 @ 
tcmalloc: large alloc 1577058304 bytes == (nil) @ 
[21672:21672:0417/205530.840031:FATAL:memory_linux.cc(35)] Out of memory.
[21798:21798:0417/205531.692125:ERROR:gles2_cmd_decoder.cc(17645)] [.DisplayCompositor-0x3ea81e801500]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[21798:21798:0417/205531.692151:ERROR:gles2_cmd_decoder.cc(17645)] [.DisplayCompositor-0x3ea81e801500]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[21798:21798:0417/205531.692418:ERROR:gles2_cmd_decoder.cc(9702)] [.DisplayCompositor-0x3ea81e801500]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[21798:21798:0417/205531.693154:ERROR:gles2_cmd_decoder.cc(17645)] [.DisplayCompositor-0x3ea81e801500]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[21798:21798:0417/205531.693170:ERROR:gles2_cmd_decoder.cc(9702)] [.DisplayCompositor-0x3ea81e801500]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[21798:21798:0417/205531.693182:ERROR:gles2_cmd_decoder.cc(9702)] [.DisplayCompositor-0x3ea81e801500]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.

Not working on this.