Summary: Where in the code does the lighting building live, and what’s special about that code as opposed to most other kinds of workloads one can run on a computer?
Background: I have a ThreadRipper 1950x / GTX 1080 Ti workstation, that runs many kinds of workloads well.
I’ve tried mining cryptocoins, playing games, running memory tests, doing 3D content creationg, and so on, and they all work well.
However, trying to build lighting in Unreal Engine makes the computer lock up hard. It generally locks up when reaching 10-30% of the lighting build.
This is the only workload I’ve found that causes this problem, so I’m kind-of interested in what could be causing it?
Does the lighting builder use the GPU? Does it generate workloads like CUDA or OpenCL?
Does it use AVX instructions? Or what else does it do, that’s not found in the same way in the other workloads I’ve used?
I’ve tried the Unreal Editor on both Linux and Windows 10 Pro, and it locks up on building lighting on both of them.
Until now, I’ve had to go to the living room gaming computer (less workstation-ey, fewer threads) when I want to build lighting, which is highly inconvenient.
I’m wondering whether I need to dive into the code to try to read what it’s doing myself to get a sense of it.
If so, where in the code base does the lighting building live?
Also, if someone has an idea of how to debug what this really is, I’d appreciate that, too.
If it matters, I’m running a ThreadRipper 1950X on an Asus Prime-399-X motherboard with 8x8GB DIMMs, running a Samsung 960 EVO M.2 (for Linux) and a Samsung 970 EVO M.2 drive (for Windows).
It happens with several versions of Unreal Engine, and with several versions of the motherboard BIOS. Using Windows 10 Pro (main ring) and Ubuntu 18.04.4 LTS, and several versions of the NVIDIA drivers on both OS-es.
The “lighting builder” is called Lightmass. If you can’t find its codebase on your own you’re not going to enjoy the experience once you do find it.
It does not use the GPU (aside from if you’ve told it to use the GPU for encoding lighting results). There IS a GPU-lightmass implementation in the dev-rendering branch that some of us were hoping would make it into 4.25, but it’s probably more likely to be at least version 4.26.
If it’s locking up then look at why it’s locking up. The crash dump should be your first point of entry to the problem, or run the editor in debug mode. You’re probably running out of video memory in general, for me at least that’s the most common form of UE error. UE doesn’t share video memory well with other programs, so when you’re building the lighting shut everything else down and walk away from the machine. I’m running on an RTX 2080Ti and I still can’t build lighting while anything else uses more than an iota of video memory.
Thanks for the suggestion. Looking for “lightmass” code sends me in the right direction.
There is no crash dump. This is a total system lock-up. In past lives, I’ve debugged kernel issues using WinDBG over FireWire, but I sure hope I won’t have to do something as terrible to debug this particular issue … in fact, not even that may tell me what’s going on, because the kernel seems just gone (both Windows and Linux.)
Pretty sure this is some kind of hardware or BIOS related problem, but I can’t figure out what it is.
Prime95 runs fine. xmrig-cpu runs fine. HDBench runs fine. Unigine demos run fine. Unreal editor and levels and games run fine. memtestx86 runs fine.
But, pressing “build lighting” in the Unreal Editor, will export lighting, and then lock up the machine.
I actually saw one lock-up, once, about halfway through installing the Unigine Superposition demo.
I wonder if it’s doing lots of disk I/O that does it? But then why do HD benchmarks work fine?
And why does it happen both in Windows (on a 970 Evo drive) and Linux (on a 960 Evo drive, in a different M.2 slot?)
Yeah, this should go into some hardware debugging forum somewhere, but the only real reproducible case I have is the Unreal lighting builder. So … what’s so special about that workload?