[BUG] EXTREME MEMORY USAGE (up to 15GB!)
sylveonsylvia opened this issue ยท 29 comments
Raze version
1.7.1
Which game are you running with Raze?
Duke Nukem 3D
What Operating System are you using?
Linux x86_64
Please describe your specific OS version
arch linux
Relevant hardware info
No response
Have you checked that no other similar issue already exists?
- I have searched and not found similar issues.
A clear and concise description of what the bug is.
when launching the game never loads and runs in the background taking up a huge amount of memory
Steps to reproduce the behaviour.
Explain how to reproduce
- launch the game
Your configuration
No response
Provide a Log
No response
I have the same issue on Steam Deck using Luxtorpeda to try and run Duke Nukem 3D Megaton Edition as well as Shadow Warrior Classic using Raze. The whole thing just freezes/crashes.
As a temporary solution to the problem, I downloaded this version of the raze https://devbuilds.drdteam.org/raze-linux/raze-linux-x64-1.7pre-469-gcfef8c8a7.tar.xz. Which works without problems, tested on Shadow Warrior Classic (Steam)
Not sure what the issue is and I don't use Linux dev tools often enough to know exactly how to diagnose this problem. @Blzut3 or @alexey-lysiuk may have some idea how to trace this down, if they have time to take a peek at this.
By the way one thing that may help is to post your config files - never know, it may be config related. Please feel free to remove any personally identifying information (i.e. real name in any search paths, etc) if it exists.
If there's some memory issue that isn't occurring at head and only in the released version, I'm inclined to just close the issue. It'd be interesting to know whether Duke 3D works on that devbuild though because that's what the OP was playing.
We haven't discussed internally when 1.8 will ship but if the current state of master is working fine, I'd rather invest time bringing 1.8 out than a wild good chase trying to fix something obscure in 1 7.x.
I'm inclined to agree, but, I'm also trying to rule out that this has anything to do with the way the binaries are being prepped. Knowing the cause of the issue might mitigate further issues into the future.
Breaking GDB on the hang blames the radeonsi shader compiler. Switching to Vulkan +vid_preferbackend 1 avoids the hang and memory usage is way down.
Unrelated to this issue, but @madame-rachelle I would suggest static linking libjpeg since the ABI situation with libjpeg is a complete mess. Debian and Ubuntu still differ here, although since the mess started Debian has reverted to the libjpeg62 ABI through libjpeg62-turbo and Ubuntu still provides libjpeg62. Only Ubuntu has libjpeg8 now. Otherwise your binaries look about right.
Got it, thank you. I try to static link as much as possible, I guess I missed one.
Switching to Vulkan +vid_preferbackend 1 avoids the hang and memory usage is way down.
Using "OpenGL ES" (vid_preferbackend=2
) also avoids the memory issue for me, and might be a suitable workaround for those who can't use Vulkan.
Considering the problem is understood, our JPEG library has just been changed anyway, and 1.8 is not too far away, I'm closing this one for now. If the issue still occurs in the next released build, feel free to re-open the issue.
I'm not sure if I'd say the problem is understood. It's only been determined that it was an issue with the shader compilation on the radeonsi (at least) mesa driver. Given other OpenGL drivers work, good chance it's a driver bug but I don't know enough to debug further than that. I also don't know how much it matters if we're pushing Vulkan as the preferred code path anyway.
(And the jpeg thing had nothing to do with this issue, only mentioned here since Rachael's binaries were brought up.)
It appears I misunderstood RE: JPEG library etc, however as you've hinted, OpenGL will eventually be dropped and as it does appear to be a driver issue, it's not something we need to hold open. The author of this bug or #986 can raise it with the Mesa devs if they wish.
Just for reference, I've confirmed this is still happening with the latest master (2916fe5) and Mesa 23.1.8 with radeonsi and zink+radv. llvmpipe and zink+lavapipe is not affected (although the latter is super glitchy). Raze 1.6.2 is not affected. Vulkan (radv) and GLES are not affected.
@coelckers do you think I closed this one prematurely? Should we look at whatever shader changes have occurred that could be breaking this open source Radeon driver or leave it as a driver bug?
Probably doesn't help narrowing things down, but again for reference: it looks like with the new 4.11.0 release GZDoom exhibits the same behavior.
If you've got the appropriate hardware, you can probably bisect it back to whatever change in the shader caused this. I just don't have the hardware to test this at all unfortunately.
Bisecting raze points to b6da4ec.
Bisecting gzdoom points to ZDoom/gzdoom@087050c
As mentioned in the issue I created, I can replicate this on my system. Vulkan does work ok if I set +vid_preferbackend 1
, but since this defaults to opengl, can be a confusing experience for someone that isn't aware of this bug.
@Blzut3 I'm going to re-open this, I appreciate the bisection but is there any further profiling you can do to determine why this may be occurring for the driver?
I know close to nothing about GPU programming and debugging so happy to try things but I don't have any intuition of what would be helpful.
Mesa 23.2 was just released. Will be interesting to see if the bug happens to be fixed. Just waiting for the Kisak PPA to update. If it's still present I might open a ticket with Mesa.
Thanks mate, I definitely appreciate your help even after I erroneously closed off the ticket. Is just a crap situation as Graf or I don't have the appropriate hardware to test this ourselves.
Mesa 23.2.1 appears to still be bugged.
Reported to Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9953
@coelckers Any comment on the UBO size from the mesa ticket? Trying to not leave the mesa devs hanging.
Raze 1.8.1 is still affected. No comment at all on the buffer sizes?