ZDoom/Raze

[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.

image

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

  1. 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.

anzix commented

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.

Blzut3 commented

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.

Blzut3 commented

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.

Blzut3 commented

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.

Blzut3 commented

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?

Blzut3 commented

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.

Blzut3 commented

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?

Blzut3 commented

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.

Blzut3 commented

Mesa 23.2.1 appears to still be bugged.

Blzut3 commented

@coelckers Any comment on the UBO size from the mesa ticket? Trying to not leave the mesa devs hanging.

Blzut3 commented

Raze 1.8.1 is still affected. No comment at all on the buffer sizes?

fixed in fe7738e

Actual fix was 292c208 but confirmed working.