I’m unsure if this is the right sub-forum to be posting this, as there does not appear to be a topic for source control.
Although this bug submission is regarding 5.0, this issue was also prominent in 4.27.
When submitting through the built-in source control interface (we’ve tried SVN, GIT, Perforce), if you attempt to submit too many changes at once, you’re greeted with an ‘out of video memory’ message. Why would source control be directly affecting VRAM? My only guess is that when preparing the assets for submission, Unreal has to verify those assets and in doing so, has to load all of them into memory.
Shouldn’t Unreal be responsible for handling this clumping of memory to avoid crashing the Editor?
For context, the machine I’m attempting this on has the following:
CPU: AMD Ryzen 7 1700X
GPU: GTX 3080, 12GB
RAM: 24 GB
I haven’t personally seen this error or heard of it until recently with UE5. There’s another guy a couple posts away having the same error, but it’s not regarding source control.
Hi @Humanasset, thanks for following this up! Interesting, I’ve had a lot of ‘out of memory’ crashes with Unreal over the years but I was unsure why source control would be problematic, considering.
Would you perhaps be able to link me to this other post? There may be a correlation
We also get this on 5.0.2 that is hooked up with source control using git. Also this came up with 4.27 while connected to source control with perforce.
Often it comes up when fixing redirects where there are quite a few that need fixing.
I’ve noticed that the actual dedicated GPU memory is fine and stays constant. It is the ‘shared GPU memory’ (uses the system RAM) that runs out. Once it does then unreal crashes with the mentioned error. 64GB in my case. The whole repo is around 80GB so this very small folder being cleaned up is very strange.
Doesn’t seem you should need any video memory to fix redirects…
I now remember I ran into this a while back just once before I realized what I had done, but I found it odd because I’m thinking GPU, but I had disabled virtual memory on my windows machine, because I have 32GB of ram on that machine and a decent GPU and thought I could get away with it regarding performance. Despite this I encountered a crash and error while working with a relatively small scene saying I ran out of video memory. I turned virtual memory back on windows and it hasn’t happened since.
It seems this issue has cropped back up in 5.4 with the addition of an additional BIsTicking check on line 240 of ScopedSourceControlProgress.cpp
// Testing if we are already ticking the rendering. That is to prevent a double "BeginFrame" in case the user wrongly uses the FSlateApplication::OnPreTick to start a slow task.
bool bIsTicking = FSlateApplication::Get().IsTicking();
In my case attempting to open the View Changes window caused the shared memory error from before, but commenting out this check and the associated parts of the conditions on lines 243 and 252 solved the issue in my case. I imagine that that check is needed however and so this isn’t really a fix per say and more of a short term workaround.