[Addressed] [GZDoom 4.1.2] "Could not create Vulkan image"

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

[GZDoom 4.1.2] "Could not create Vulkan image"

Postby axredneck » Tue May 21, 2019 4:23 pm

GZDoom crashes with "Could not create Vulkan image" error message.

How to reproduce:
- Enable Vulkan
- Restart GZDoom
- Load saved game
- Load saved game again

GZDoom 4.1.2 built from sources, PLUTONIA.WAD from Steam, no mods, Arch Linux, Geforce GTX 1050 (driver 430.14).

Log and gzdoom.ini attached.
Attachments
gzdoom.ini
(56.26 KiB) Downloaded 16 times
gzdoom.log
(2.54 KiB) Downloaded 15 times
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby dpJudas » Tue May 21, 2019 4:30 pm

Did you build 4.1.2 or latest master? If you used 4.1.2, please try again with master just to be sure it isn't something already fixed.

Edit: just for the record, works just fine on my computer to load savegame multiple times in a row (on master)
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby axredneck » Wed May 22, 2019 1:51 pm

I tried master 2 days ago - the same issue. Will try again today.

How to reproduce more reliably:
- Load saved game
- Play a bit
- Quickload
- Play a bit
- Quickload again

Edit: tried current master - still an issue.

Edit2: tried with DOOM2.WAD and new game - no issue. Maybe my savegame of Plutonia is corrupted but with OpenGL and Softpoly it works well but with Vulkan it crashes.

Edit3: deleted gzdoom.ini, tried the same Plutonia savegame - no issue.
Attachments
save12.zds
(121.06 KiB) Downloaded 9 times
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby _mental_ » Wed May 22, 2019 2:17 pm

You shouldn’t delete .ini file, but rename it. Apparently, a particular combination of settings caused this issue. How can we figure out this without old configuration file?

EDIT: Did .ini file attached in OP cause the bug?
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby axredneck » Wed May 22, 2019 2:19 pm

Yes, i renamed it, not deleted.
EDIT: Did .ini file attached in OP cause the bug?

Yes, it does. This config, save12.zds (attached above) and PLUTONIA.WAD from Steam's Final Doom.
MD5sum of my PLUTONIA.WAD is 75c8cf89566741fa9d22447604053bd7.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby axredneck » Wed May 22, 2019 6:30 pm

I just reproduced the same issue without savegames:
- Use GZDoom with my config (attached above)
- Try to play this map: https://www.doomworld.com/idgames/level ... d-f/europe
It crashes with different errors each time, sometimes it's "Could not create Vulkan image", sometimes it's something different.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby Marisa Kirisame » Thu May 23, 2019 4:27 am

Ah, I suppose it's the hq resize. The 1050 has very little VRAM, doesn't it?

I did notice that with 6x resizing, loading map24 of plutonia, then saving and reloading the save, made VRAM usage from gzdoom alone to rise to 2.5GB.

In my case, with a 6GB 1060 I can easily reproduce this error by loading Total Chaos with those resizing settings.
User avatar
Marisa Kirisame
ZScript Magician
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: Marisa Kirisame#4689
Twitch ID: magusmarisa
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby Graf Zahl » Thu May 23, 2019 6:47 am

And in that case the fatal error is expected behavior. I have complained several times myself about the usefulness of these excessively high scaling factors, but some people seem to be too attached to "more pixels" that removing them is not an option. Just one word: They are not meant for low RAM graphics hardware! BTW, 6x scaling more than doubles video ram usage over 4x while providing virtually no improvement whatsoever.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby _mental_ » Thu May 23, 2019 7:09 am

Taking into account that vkCreateImage() fails only with out-of-memory codes, we can revise the error message.
Probably, this applies to some other functions as well. I guess, getting out-of-memory on texture allocation is just the most common case.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby dpJudas » Thu May 23, 2019 7:16 am

I just pushed a commit that adds the VkResult status code to vulkan errors. Now it will include it failed due to memory allocation failure.

I also changed how vulkan errors are reported - before it was a bit random if it throwed CRecoverableError or CFatalError. The issue was that CFatalError couldn't be used during initialization, but on the other hand CRecoverableError can't be used after initialization. Vulkan is an API with virtually no error checking, which means that restarting rendering randomly will never work as the general code now don't know which state the various vulkan objects were left in. I solved this by adding a CVulkanError type that the init code can catch and use for falling back to OpenGL, but also will cause a fatal error if such an error is thrown later on.
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby MasterBeavis » Thu May 23, 2019 7:35 am

should i give this new build a try and post the log from amd crash again?
User avatar
MasterBeavis
 
Joined: 13 May 2019
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby dpJudas » Thu May 23, 2019 7:47 am

No, I don't think your crash is related to this. Your log files didn't have any error messages in them.
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby axredneck » Thu May 23, 2019 1:49 pm

I forgot that i set 6x scaling (yes, it doesn't look much different from 4x). I thought i have enough VRAM because OpenGL didn't complain, so i thought it's a bug of Vulkan renderer.
Rebuilt git master, tried europe.wad again with 6x scaling, now it says that i have not enough memory. I will play with 4x from now.
Here is a log:
Attachments
gzdoom.log
(2.21 KiB) Downloaded 11 times
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby axredneck » Thu May 23, 2019 2:00 pm

The same europe.wad, the same config but 4x scaling, "Out of device memory" after loading quicksave. Will try with 2x. Does Vulkan consume much more VRAM than OpenGL?
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: [GZDoom 4.1.2] "Could not create Vulkan image"

Postby dpJudas » Thu May 23, 2019 2:12 pm

Yes and no. Memory management is more manual in vulkan so it is quite plausible the current implementation uses more memory than OpenGL.

There's currently two main things that will increase the memory requirements for sure: memory resources aren't released until the end of a frame if no longer needed, which may affect precaching. I'm not 100% sure without looking closer at the code. And then strictly 2D textures will use approx 66% more memory due to mipmaps always being allocated for them.

Last, there's the chance an OpenGL driver might attempt to compact memory when running low. I think the vma allocation library used for vulkan supports something like this, but I'm not sure how nasty it would be to hook up.
Last edited by dpJudas on Thu May 23, 2019 2:13 pm, edited 1 time in total.
dpJudas
 
 
 
Joined: 28 May 2016

Next

Return to Closed Bugs

Who is online

Users browsing this forum: MSN [Bot] and 1 guest

cron