ZDoom

I used Nash's PDA starter kit for replicating this crash.
viewtopic.php?f=105&t=65849

Opening the PDA and leaving it open for about 30 seconds will cause GZD to crash with this error "Could not allocate memory for vulkan buffer: out of device memory crash". Is this related to GPU by any mean?

This sounds very much like a problem that I had with 4.7.0 but I have not seen it since the dev builds were changed to fix it and I can't make it happen with 4.7.1 either.

Using my own test files and Nash's kit, I can have the PDAs open for several minutes and not experience a crash. I've ran it with the garbage collector stats on screen it there doesn't seem to be a problem there.

So I'm not sure why this is crashing for you. I was going to suggest that you'd inadvertently run it with 4.7.0 but I see from your crash report that isn't the case.

Seems to be an AMD-only thing. I am also unable to repro it with PDA Kit 1.2 and GZDoom 4.7.1.

Perhaps AMD cards have less memory available for vertex buffers?

Edit: looking at the memory stats at gpuinfo.org for that particular GPU makes it a bit more mysterious. It reports 3 different vulkan heaps: two that are 8 gigs in size and one that is 256 megabytes.

F2DVertexBuffer specifies that the memory is not static, which makes VKBuffer::SetData require a memory heap that is both host visible and device local. That means heap #2 that is only 256 MB in size. Now the question is, does the GC kick in before that?

AMD does indeed provide only 256 MB of host visible memory. They surely know how to cripple their cards.
The main question should be whether it is necessary to use host visible memory for these static 2D vertex buffers or if the code can be rewritten to use another type of memory.
A large portion of this heap is already used for the persistently mapped buffers so using it for convenience for all buffers may not be such a good idea.

Unless I am missing something, those vertex buffers used by this feature does not have to pass in false when calling SetData. If the hardware layer tells the vulkan backend the buffer is static then it will create a transfer buffer in system memory (heap #1 for this card) and then transfer it to a vertex buffer in video memory (heap #0).

Correct. These buffers are supposed to be static. Considering that they can be longer lived they really should not occupy such a limited resource as host visible memory.

I created a PR fix for this: https://github.com/coelckers/gzdoom/pull/1497. Note that since I don't own an AMD card I can't actually confirm it fixed it. It should though, as this will make it use a different heap for the 2D drawer.

Tested with the latest dev build. Can confirm it's fixed. I left the menu opened for 5+ min and no crash. Things will occasionally lag when the GC starts doing its cleaning (I don't actually know what is going on but i'm assuming it's that) but definitely no crash. Thank you so much for fixing this.

Ghost Prototype wrote:Things will occasionally lag when the GC starts doing its cleaning

Huh, strange... I thought that was already fixed...

You cannot really fix that. When the GC starts its cleanup it needs to free a lot of objects and that costs time. Depending on the type of objects it can indeed cause some lag if taking them down is a non-trivial affair.

I'm using 4.7.1 dev build and this bug crashes the game
https://devbuilds.drdteam.org/gzdoom/gz ... 49a0d8f.7z

I'm using Project Brutality Custom Build from this link:
https://telegra.ph/Project-Brutality-Custom-Build-03-05

When I am running PBCB with OpenGL API, the .m3D and voxel models are rendered incorrectly. This is due to AMD no longer fixing OpenGL bugs or paying any attention to it, since OpenGL is obsolete and is being supplanted by Vulkan.
Has a novel look because of the reshade.me filters that were chosen. Plays well, has some screen tearing.

When I run PBCB with Vulkan API, the 3D and voxel models are rendered correctly. The reshade.me filters are disabled, but framerate is good and it plays great, until it crashes with the Vulkan Buffer: Out of Device Memory.

I thought the Vulkan bug was fixed in the 4.7.1 dev builds?

Any suggestions what I could try?

I'm updating my AMD drivers from 22.2.3 to 22.3.1. ATM
PBCB is a really nice mod pack, I don't mind spending some time to troubleshoot it.

Thanks for your time reading this, and I look forward to your input!

Please make a new thread.

As of using the 4.8 dev build. I no longer have this crash.

Major Cooke wrote:Please make a new thread.

Because of Necroposting or because dev builds have reached version 4.8.1?