WASM Threading memory out of bounds

[Jens_Munk_Hansen]

Hi Developers

I can get WebGPU to work fine with the release candidate 9.4.0. I am little puzzled, why you require “-sASYNCIFY” to be used. I would prefer the calls to be blocking, e.g. GetRenderWindow().

I am working on establishing a better debug, but currently I ran into some memory if build with threading (32-bit).

My build setup (external project using VTK).

list(APPEND emscripten_link_options
    "-lembind"
    "-sWEBGL2_BACKWARDS_COMPATIBILITY_EMULATION"
    "-sMODULARIZE=1"
    "-sASYNCIFY=1"
    "-sASYNCIFY_STACK_SIZE=81920"
    "-sEXPORT_ES6=1"
    "-sALLOW_MEMORY_GROWTH=1"
    "-sEXPORT_NAME=VtkwebAssemblyModule"
    "-sEXPORTED_RUNTIME_METHODS=['ENV', 'FS', 'ccall', 'stringToNewUTF8', 'addFunction']"
    "-sEXPORTED_FUNCTIONS=['_free', '_malloc']"
    # "-sDEFAULT_LIBRARY_FUNCS_TO_INCLUDE=['$addFunction']" # CMake adds another $ sign!
    "-sINCLUDE_FULL_LIBRARY" # for addFunction
    "-sALLOW_TABLE_GROWTH=1"
    "-sERROR_ON_UNDEFINED_SYMBOLS=0"
)
if (ENABLE_THREADING)
  list(APPEND emscripten_link_options
    "SHELL:-s USE_PTHREADS=1"
    "-pthread"
    "SHELL:-s PTHREAD_POOL_SIZE=4"
    "SHELL:-s OFFSCREENCANVAS_SUPPORT=1" # Proxy rendering to main browser thread
    "SHELL:-s ENVIRONMENT=web,worker"
  )
else()
  list(APPEND emscripten_link_options
    "SHELL:-s ENVIRONMENT=web"
  )
endif()

I am using your most recent docker images. Your 32-bit works fine, the 32-bit with threading gives me the memory out of bounds at startup. I can see that WebGPU is found and the adapter information.

Any hints are welcome. If not, I will work on establishing a better debugging setup.

Thanks
Jens

[Jens_Munk_Hansen]

Without threading, things works great. I also a little puzzled why I don’t get into the vtkWebGPUPolyDataMapper.

[jaswantp (Jaswant Panchumarti (Kitware))]

@Jens_Munk_Hansen

I can get WebGPU to work fine with the release candidate 9.4.0. I am little puzzled, why you require “-sASYNCIFY” to be used. I would prefer the calls to be blocking, e.g. GetRenderWindow().

Simple answer is that webgpu (unlike webgl2) is async only. This has a contagious effect, requiring everything else (even embind funcs to become async)

@Jens_Munk_Hansen

I am using your most recent docker images. Your 32-bit works fine, the 32-bit with threading gives me the memory out of bounds at startup. I can see that WebGPU is found and the adapter information.

This looks like a static initialization issue. Cpp call stack with line numbers would definitely be helpful.

[Jens_Munk_Hansen]

I realized that and changed a bunch of JavaScript code to handle the async nature. I will try tomorrow to get it to run in debug, so I get the callstack. I agree, it seems like an initialization issue. In debug mode, I got a some trace…

Tomorrow, I will try to establish a setup for debugging. I managed to do this before, but only for debugging my own code and the code from Emscripten.

[Jens_Munk_Hansen]

I figured it out. It was a simple out-of-memory. If I set the initial memory size, -sINITIAL_MEMORY=1GB, it went away. It was in the creation of a vtkBuffer, perhaps I should double check if we allocate memory here without handling out-of-memory properly.

[jaswantp (Jaswant Panchumarti (Kitware))]

Ah. Glad you figured it out. I vaguely recall seeing similar callstack not long ago that said table index was out of bounds. I’ll have to update the vtk emscripten docs page with this info.

[Jens_Munk_Hansen]

I did an interesting find. Random access to points and computing distances to a fixed point. I did this to investigate -msimd128 and it turns out that no vectorization is made unless points are on a 16-byte boundary. Therefore invented a vtkScaledAOSDataArray (with padding). More interesting even without SIMD, the aligned memory is twice as fast as non-aligned memory. It has a significant impact reading less memory.