Noticing light build time difference on project between AMD Ryzen and Intel I7

I was on a conference call tonight with two other people where we are all working on an Unreal Project. We were discussing optimization and how some of the things we were doing were reducing lightbuilds rather well and 2 of us mentioned how our time was down to 21 minutes for this larger project. The other guy said wow, his time for the exact same project (we all pull the same project from GIT) was only 7 minutes. This made no sense. Me and the other guy who were at 21 minutes are using newer Ryzen 3950x machines with 32 gigs and 64 gigs of high speed ram. One is running a 3090 RTX and I am running a 2080TI RTX. Both of us have very fast hard drives.

The guy getting the 7 minutes is using an older machine with an Intel I7 and 64 gigs of ram with a 2060 RTX. We all ran the task manager when we were doing the light build and noticed the following in the UE Swarm. The Intel and the Ryzen had almost the same times and 100 % utilization of the CPU during the Caching Irradiance Photons. During the Skylight Radiosity phase, the Intel smoked the Ryzen since it maintained 100% cpu utilization and and Ryzens only managed maybe 9-14%. This is crazy. Then, in the final phase of Processing Mappings, The Intel slowed down and the Ryzen went much quicker with 100% utilization of the CPU. Still, it was not enough to make up the crazy difference during the Skylight Radiosity. My buddy with the Ryzen (like mine) was so ****** that he loaded the project on his other machine with an older Intel and the same thing happened seeing 100% utilization of the cpu from the Intel.

Can someone please explain to me how this is and is there anything that can be done to improve the Ryzen times? Thank you!

I’m on a Ryzen 3900x and my processor is pegged at 100% through pretty much the entire lighting build including skylight radiosity (dipping only briefly toward the end)

Yes, this is becoming a problem that I am able to repeat. I just downloaded the Grocery Project from Unreal and tested this and AGAIN, I saw the utilization issue during the light build. You should try downloading that project (it is free for the month) and seeing what you get for a light build time. I would be very curious.

It’s hard to say what it could be, you didn’t say what the i7 model was and it could be the case that while it may have fewer cores it could be a higher clock speed. With building lighting each mesh in the scene gets built on one thread and multiple threads can’t work on the same object. So what can happen is if you have many cores that aren’t as fast they can quickly go through simpler objects but when it gets to something more complex it will take longer which can result in threads finishing their work and not doing anything while they wait for other threads to finish with more complex objects.

Totally agree with what you describe but what I am seeing now is that there is no issue with the Ryzen 3900x. It appears this CPU will run at 100% utilization where the 3950x will not.

The type of Intel cpu doesn’t seem to matter. I can throw this scene on my newer or older I7 and the results are the same with regards to the utilization.

This is a big issue since the overall build time is much less on the “lower speed” cpus I am mentioning. I would not be concerned if it was a minute or two but 60%+ is an issue after spending 3,000 dollars to build this machine.

What settings should I use? Defaults? And the light build quality? Preview mode?

For your CPU have you looked into updating the firmware on your motherboard? Most of the available motherboards that can support the 5950X need a firmware upgrade for it

Using preview build on my 3900x (stock speeds, aftermarket air cooler): Skylight radiosity starts off at 100% then quickly sinks to 4% cpu utilization. Despite that it finished in 3 mins (180.5s). Processing mappings went at 100%~ the entire way through, finishing in 6.5~ mins (400s). So roughly 10 minutes for the total build.

Not going to bother with anything above preview because I think the problem is obvious:

Unsurprisingly, exactly as darthviper107 described above: The author uses one huge mesh for the entire building and it takes forever to bake it because lightmass only processes one mesh per thread.

I can’t explain why you seem to have consistent 100% CPU utilization across your intel processors but regardless, this isn’t a good way to build a scene. Taking 3x as long to build on a Ryzen processor seems excessive, but it makes sense that a processor with better single core performance would build this project more quickly, because the entire lightmass build is being held up by a single mesh.

Very interesting results. So you are saying that in your previous post where you had 100% cpu utilization, the meshes in your scene were more broken up into separate meshes? I essentially have the same results on my 3950x. I forgot about the statistics window and I am going to pull that up for the intels.on trying to back the same scene. I am using preview as well.

Yes. I design all my scenes this way. Some people like to merge static meshes to reduce draw calls but I don’t bother as most of them just get batched together anyway.

The draw calls would impact the real time performance, I guess, but that is not an issue for me. It is this light build. I don’t mean to take up more of your time as you have been helpful so feel free to let this go.

When I do an asset like a couch, table or what have you in 3dsmax, I do often attach my individual uvmapped objects into a larger mesh, especially if I need to instance them multiple times. I guess it is the draws I want to limit as well as the many, many objects I then have in the outliner.

When it comes to a larger asset like a building, I would often have the meshes broken apart into separate meshes such as the exterior walls, interior wall, roof, windows, etc. I do this because of wanting to cull objects out of view from the camera. My understanding, based on logic, is that unreal will not cull an object like a wall if it is attached to a mesh where even a part of that mesh is in the camera view.

When it comes to the light build, my approach should work for the better according to you and darth viper since I am breaking things apart into individual meshes.

As of like… 4.19 or so, I can’t remember the exact version, the mesh drawing pipeline was refactored such that Unreal batches static meshes that share the same material/mesh together into a single draw call. Before that though you could make a construction script that replaced all of the individual static meshes with HISMs, but it was inconvenient and most people didn’t want to bother setting it up so the easy solution was to just merge meshes into a single static mesh.

Also I should mention something I forgot in my previous post: Because lightmass processes meshes on different threads, you can sometimes get noticable variation in the lighting on surfaces that are supposed to be continuous. This can usually be resolved with higher quality lightmass settings, but another way to address it is to merge the meshes together into a single mesh to force them to be processed on the same thread. If you do this then the merged mesh will take longer to build, but you’ll be able to use less aggressive lightmass settings which will most likely result in a faster total build time. Something to keep in mind.

Not entirely sure I understand what you’re saying here, but afaik yes, the engine won’t be able to efficiently cull objects if you merge them all together, and lightmass will build it slower. So it’s best to keep your meshes fairly modular unless, as I mentioned above you want to merge meshes together to avoid discontinuous lighting. Only merge objects that share a continuous surface though, unless you’ve got some weird structure that is only made up of curves, there’s probably no reason to flatten an entire building down to a single object.

Super helpful response and input, Arkiras. Thanks again!

I hate to keep this post going and would have loved to have said what was discussed made sense and explained the issue away but after further tests, it is not. The Ryzen 3900x has 24 threads and the 3950x has 32 threads. Using the logic that one static mesh at a time can be done on a thread, the 32 thread 3950x should crunch light builds more quickly but it does not. I redid the Grocery store scene and tracked the light build stats and it was actually a bit slower than the posted 3900x times.

This same issue was brought up in the thread below and at the time, some people thought changing some settings in the swarm agent resolved the issue. Maybe in that version of unreal it did but it made not one bit of difference in mine.

Again, the whole static mesh thing per thread was mentioned in that older thread which makes sense but it does not appear to be what the issue is since the Ryzen 3950x is NOT outperforming its smaller brother the 3900x.

I just did another light build in my project I had mentioned above and it is a larger scene than the Grocery store but does not have larger single meshes but again, my 3950x is never utilized above the 15% during the main part of the light build.

Try this as a test:

In world settings, set skylight bounces to 100. Then set lightmass quality to production and do a lighting build and let it run for a bit (3-4 mins) before cancelling it and observe the CPU usage. (Don’t bother trying to finish the lighting build, it will most likely take days… maybe weeks)

Does your processor still never hit 100% utilization? (or at least 89-90%)

I dont think that’s it, but since ryzen is relatively newer…
Could it be that swarm is optimized for Intel usage and not for AMD?

Also, if I remember correctly (haven’t set up to build light intensively in a year or so) the engine used to use a suite of Intel tools to operate swarm and lightmass. At least from what I remember they were Intel tools, or either way, something requiring an extra paid license. Sure would help if I remembered what it was wouldn’t it?

All that said.
You also have to consider that Intel actually optimizes FOR unreal…nd-unreal.html

I haven’t read any similar things from AMD, nor have I ever looked to be honest.
But maybe this provides a reason as to the why.
Essentially, we need to go Bug the **** out of AMD until they optimize the cores for the program (fat chance) ;p

And when I said cores, I guess I sort of hope Bios? So anyone can update and benefit?

Perhaps I missed it but there don’t appear to be any intel-specific optimizations here. Most of this article is about setting up swarm, and the only Intel significance is just that they used NUCs (intel’s mini-PC) to build out their swarm.

FWIW: Here’s an actual benchmark comparison in Unreal Engine: Unreal Engine: AMD Ryzen 5000 Series CPU Performance

TY for url, and while I just bought ryzen 3000 series, and won’t get that kind of perf. its STILL tons better than what I left behind being outdated , i5-3570, so I can’t complain. The 3600 I just bought is but a stepping stone, but a worthy stone.

Hello Arkiras. I finally got around to doing this. I did both the scene I am currently working on as well as the Grocery store. In my scene, it actually does hit 100% for the first part of the radiosity portion but then it dies down to real low utilization. The Grocery scene went to a very low utilization right away during radiosity. Now the CPU will hit mostly 100% utilization during the final lightmap gathering portion but that is not where I need the full utilization. I just do not understand what the issue could be. I am considering updating chipset drivers and possibly getting another SSD but I seriously doubt either one address this.

According to those benchmarks for the Puget system, my processor should be faster than the 3900x in a light build but that is NOT the case.