PVRTextureTool during Mac Build uses only one core

We have a moderate size iOS app that is very slow to build. Our build machine is a maxed out Late 2013 8-core Mac Pro w/ 64 gigs of RAM. We’re currently on 4.6.1 release. Each device build take hours. Five or six hours on this beefy machine. When our team members working on laptops go to do device builds, it can take 12-15 hours or even more.

This is really unacceptable and is slowing us down.

Watching the build in top, the build uses a decent amount of all 8 physical cores during the earlier parts of the build (though doesn’t appear to be taking advantage of hyperthreading), however, once it gets to doing PVR compression using PVRTexTool, it starts using only a single physical core, hovering between 90 and 95% utilization of a one core while the rest sit idle.

Is there any way we can workaround this? Are there any plans to fix it in future releases Ideally, it should be compressing on at least 8 threads to maximize the use of system resources.

I believe this might be a known issue which we are hoping to fix in the near future. The problem is to ensure the editor doesn’t eat up too many resources when in the background, we reduce usage of a number of things. Why does this matter? Well, the cooker is just the editor running stand-alone, so when the build process kicks off the cooker, it creates an editor running in the background and after about 15 seconds or so that process kicks in to low resource mode and stops utilizing more than one core.
There is a very hacky work around for people who are at their machine. There will be a second editor instance running on the shelf. Clicking on that and making it have focus will kick the process back to the foreground which will enable it to use all the resources again.
I’ll bump this issue up in priority and see what we can do about getting it resolved sooner rather than later.

Thanks for the information. Would renice-ing the build process to a higher priority help at all? What about doing the build from Xcode or the command line instead of the UE editor?

So, for the record, I tried renicing the process to -20 (both the spawned process and the original one) after kicking off the build. It finished in 1.5 hours on an 8-core Mac Pro (Late 2013), which is much better than the 5 hours the previous builds have been taking.

Howdy ,

Sorry about the late response. Just wanted to check in with you and see if your build time have been shorter as of late. Please be sure to let me know so that I may be able to close out this issue or further investigate.

Thanks and have a great day!

Sean:

We haven’t upgraded our engine since I posted this. We tried a few of the 7 previews, but never got far enough to do a build.

That being said, bringing the second instance of UE4 to the front, and renice-ing all of the UE4 processes to -20 does get us more acceptable build times.

Since the build times have been decreased, would you be ok with closing out this post since Peter has stated that this is a know issue? If closed and you see the issue continue to occur, you could reopen this issue so that I would be able to further investigate.

Sure, that’s fine.

Has there been any progress on this? We have finally managed to get automated builds using Jenkins, but anytime we rebuild lighting it takes several hours to create a build unless someone logs into the Mac and gives focus to the UE4Editor process (which drops the build time to 15 minutes).

I tried modifying the engine to get rid of the “low profile” mode but nothing I did worked. I tried making UEditorEngine::ShouldThrottleCPUUsage() return false when running a commandlet (which should be the case when cooking), but it had no effect, which leads me to suspect something else is at work here. The editor is sleeping something between 20 and 40 seconds between each texture that needs to be compressed. This only happens when compressing textures, which uses async tasks, but I couldn’t find which could be causing the async tasks to wait so much time.

At least a pointer towards where I could look (and hack) in the code would be helpful.

Hi manoelneto,

On what version of the editor are you currently running?

Is your slowdown issue also occurring during the PVRTextool compression or just compression in general? If it’s the latter, this may be a separate issue.

I’m still on 4.5.1, but I was looking through the master branch source code trying to see if there is any changes about this and couldn’t find anything (or I’m not looking at the right places).

The problem happens only when cooking new/modified textures. During other steps of the cooking/packaging process CPU usage is normal, but is abnormally low while compressing textures. It doesn’t seem to be PVRTexTool: it only shows up in the activity monitor for a brief moment and then UE4Editor will idle for several seconds before firing it up again.

Bringing the UE4Editor process to foreground by clicking on its icon on the dock greatly speeds up the process and increases CPU usage. Switching away the focus to any other app drops the CPU usage and slows down the build time.

Here are the timestamps for compressing two lightmaps. It takes around 7 minutes to compress two textures In background and only four seconds in foreground. The suggestion for using nice/renice to increase process priority cannot be used in my case, since I’m using RunUAT.sh to build, unless I modify the UAT.

ok, I hate to do this since you’ve posted so much info here, but as your issue isn’t involving PVRTexTool and its use of a single core specifically and this thread was, do you mind starting a new thread and shifting your information into it? That issue was fixed and yours is almost certainly something else.

Thanks very much!

I’ll do that. I have been a bit reluctant about posting questions since we couldn’t afford time to upgrade from 4.5.1 yet (the project is pretty far along) and have been making do with backporting bug fixes from the newer versions when necessary.