RasPi CM5 4GB + Raspbian OOMs building 1.4.328.1

[allanmac]

C++ files in the 1.4.328.1 Vulkan SDK are OOM'ing when building on a 4GB RasPi 5 using both gcc and clang.

I suggest either the docs get updated or a hint left on how to disable aggressive OOM killing (if, in fact, that's the proper solution).

If possible, the problematic C++ files could also be massaged to consume less memory.

Details

The Vulkan SDK's Raspbian (Raspberry Pi OS) build dependencies section warns against using more than -j 1 procs on a RasPi device.

However, with the 1.4.328.1 SDK both clang-19 and gcc 14.2 are OOM'ing and being terminated when building with -j 1 on a 4GB CM5 compute module running the latest 64-bit Raspbian OS (6.12.x).

Specifically:

• clang-19 - OOM at: framework/decode/CMakeFiles/gfxrecon_decode.dir/__/generated/generated_vulkan_json_consumer.cpp.o
• gcc 14.2 - OOM at: layersvt/CMakeFiles/VkLayer_api_dump.dir/api_dump_handwritten_dispatch.cpp.o

With gcc the OOM is:

Oct 20 13:37:20 cm5 kernel: Out of memory: Killed process 46042 (cc1plus) total-vm:2217760kB, anon-rss:2041472kB, file-rss:22448kB, shmem-rss:0kB, UID:1000 pgtables:1184kB oom_score_adj:0

Workaround

The workaround for my system and verified with gcc is to disable MGLRU as described in various RPiOS OOM posts:

$ cat /sys/kernel/mm/lru_gen/enabled
0x0003

and then:

$ echo 0 | sudo tee /sys/kernel/mm/lru_gen/enabled
0

I didn't test clang with MGLRU disabled.

[charles-lunarg]

This is 100% the fault of recent api_dump refactor which made use of C++ templates to handle the three output backends. It makes the codebase much easier to maintain at the cost of increasing the compilation complexity.
The 'full solution' is to refactor api_dump some more to move the generated code out of the C++ templates. There isn't a timeframe for that unfortunately. It shouldn't be too difficult to move the api_dump.h helper functions into a form that could have the runtime 'decide' which outputter to use without plumbing the type through every function in the chain.