Vulkan still crashes when performing actions or after loading in a new map they are random but happen mostly in these cases
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 8:31 pm
by dpJudas
Which card are you using? Bit surprised to see the vulkan driver report itself as "Unknown AMD GPU".
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 8:38 pm
by MasterBeavis
GIGABYTE RX 480 4GB
Intel i5-6402p 2x4GB DDR4
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 8:40 pm
by dpJudas
Uhm, the startup log says its an AMD discrete GPU, not an Intel integrated one. Do you have an AMD GPU in the computer?
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 8:42 pm
by MasterBeavis
yea its not integrated its the AMD RX 480 4GB GPU i just listed my CPU for reference lol
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 8:53 pm
by dpJudas
Something weird is going on with your vulkan driver. I'm not familiar enough with AMD to say for sure how old your driver is, but the driver itself doesn't seem to be able to tell GZDoom the name of your card (very weird) and vulkan.gpuinfo.org only lists RX Vega and RX 580 Series for that driver version.
Please try download the very latest (seems to be a new one just a few days old) and see if the problem persists.
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 8:55 pm
by MasterBeavis
I did that about 2days ago used DDU and freshly installed the driver. using Adrenalin 19.5.1
Spoiler:
Radeon Settings Version - 2019.0509.2042.37257
View Release Notes - https://www.amd.com/en/support/kb/relea ... win-19-5-1
Driver Packaging Version - 19.10.15.01-190509a-342342E-RadeonSoftwareAdrenalin2019
Provider - Advanced Micro Devices, Inc.
2D Driver Version - 8.1.1.1634
Direct3D® Version - 9.14.10.01394
OpenGL® Version - 26.20.11000.13558
AMD Audio Driver Version - 10.0.1.10
Vulkan™ Driver Version - 2.0.87
Vulkan™ API Version - 1.1.106
Graphics Card Manufacturer - Powered by AMD
Graphics Chipset - Radeon (TM) RX 480 Graphics
Device ID - 67DF
Vendor ID - 1002
SubSystem ID - 22D4
SubSystem Vendor ID - 1458
Revision ID - C7
Bus Type - PCI Express 3.0
Current Bus Settings - PCI Express 3.0 x16
BIOS Version - 015.050.000.000
BIOS Part Number - 113-xxx-xxx
BIOS Date - 2016/10/26 10:28
Memory Size - 4096 MB
Memory Type - GDDR5
Memory Clock - 1750 MHz
Core Clock - 1290 MHz
Total Memory Bandwidth - 224 GByte/s
Memory Bit Rate - 7.00 Gbps
2D Driver File Path - /REGISTRY/MACHINE/SYSTEM/CurrentControlSet/Control/Class/{4d36e968-e325-11ce-bfc1-08002be10318}/0000
OpenGL® API Version - 4.6
OpenCL™ API Version - 2.0
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 9:00 pm
by dpJudas
Try the second newest then. The driver really isn't supposed to say Unknown AMD GPU. The gpuinfo.org database only has one entry for a GPU reporting itself like this and it was an ancient driver on opensuse. Maybe someone more familiar with AMD can give some input here on what could be causing the driver to malfunction like this.
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 9:06 pm
by MasterBeavis
This same crash was happening on the last Driver 19.4.1 aswell so idk what to tell ya
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 9:09 pm
by dpJudas
The thing is, I don't know if the driver not knowing its own card is the cause of the bug (driver malfunction) or just some simple mistake (in the driver).
I need reports from other AMD RX 480 owners to know if this is a local problem on your computer or a general problem. So if anyone reads this that own such a card, please report in if you're experiencing crashes as described here, and also what name GZDoom writes for your card.
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Tue May 14, 2019 10:08 pm
by MasterBeavis
Heres another Crash while playing Doom 4 Doom. just incase this crash is diff
EDIT. Uploaded a Crash from just playing Vanilla Doom 1 with the Unofficial Heavy Metal Soundtrack Mod. titled DOOM.zip
GZDoom doesn't crash for me on RX Vega with the same drivers. However, I've got the following validation errors. Usually, this happens after saving a game for the second time.
[vulkan error] vkCmdBlitImage(): Cannot use image 0xc4 (layer=0 mip=0) with specific layout VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL that doesn't match the actual current layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. The Vulkan spec states: srcImageLayout must specify the layout of the image subresources of srcImage specified in pRegions at the time this command is executed on a VkDevice (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdBlitImage-srcImageLayout-00221)
Called from VulkanDevice::DebugCallback at src\rendering\vulkan\system\vk_device.cpp, line 408
Called from VulkanCommandBuffer::blitImage at src\rendering\vulkan\system\vk_objects.h, line 740
Called from VkPostprocess::BlitSceneToPostprocess at src\rendering\vulkan\renderer\vk_postprocess.cpp, line 119
Called from VulkanFrameBuffer::RenderViewpoint at src\rendering\vulkan\system\vk_framebuffer.cpp, line 483
Called from VulkanFrameBuffer::WriteSavePic at src\rendering\vulkan\system\vk_framebuffer.cpp, line 335
Called from <lambda_4fd2615deee77778d0675aedcb1eb415>::operator() at src\g_game.cpp, line 2165
Called from D_Render at src\d_main.cpp, line 379
Called from PutSavePic at src\g_game.cpp, line 2167
Called from G_DoSaveGame at src\g_game.cpp, line 2225
Called from G_Ticker at src\g_game.cpp, line 1063
Called from TryRunTics at src\d_net.cpp, line 1985
Called from D_DoomLoop at src\d_main.cpp, line 1026
[vulkan error] Submitted command buffer expects image 0xc4 (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, image 0xc4's current layout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL.
Called from VulkanDevice::DebugCallback at src\rendering\vulkan\system\vk_device.cpp, line 408
Called from QueueSubmit::execute at src\rendering\vulkan\system\vk_builders.h, line 1307
Called from VulkanFrameBuffer::FlushCommands at src\rendering\vulkan\system\vk_framebuffer.cpp, line 236
Called from VulkanFrameBuffer::FlushCommands at src\rendering\vulkan\system\vk_framebuffer.cpp, line 262
Called from VulkanFrameBuffer::WaitForCommands at src\rendering\vulkan\system\vk_framebuffer.cpp, line 280
Called from VulkanFrameBuffer::CopyScreenToBuffer at src\rendering\vulkan\system\vk_framebuffer.cpp, line 765
Called from VulkanFrameBuffer::WriteSavePic at src\rendering\vulkan\system\vk_framebuffer.cpp, line 343
Called from <lambda_4fd2615deee77778d0675aedcb1eb415>::operator() at src\g_game.cpp, line 2165
Called from D_Render at src\d_main.cpp, line 379
Called from PutSavePic at src\g_game.cpp, line 2167
Called from G_DoSaveGame at src\g_game.cpp, line 2225
Called from G_Ticker at src\g_game.cpp, line 1063
Called from TryRunTics at src\d_net.cpp, line 1985
Called from D_DoomLoop at src\d_main.cpp, line 1026
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Wed May 15, 2019 8:16 am
by dpJudas
Pushed a fix for the validation errors. No idea if that explains the crash here though.
I remain skeptical of the sanity of a system where the driver doesn't even know the name of its own card. I still need confirmation from another RX 480 owner that those crashes are normal for this card and that it is expected behavior of this driver to write Unknown AMD card for this model.
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Wed May 15, 2019 8:24 am
by MasterBeavis
is there anything i can do to give more info to yall?
Re: [GZDoom 4.1.2] Vulkan Crashes
Posted: Wed May 15, 2019 8:28 am
by dpJudas
You can try the next nightly build and see if it fixes the crash. Other than that there's not so much you can do right now.
I'm currently trying to determine which computers and cards are affected as I need to find a pattern in why it crashes on your computer and not on mine (and seemingly not on _mental_'s RX Vega either). It could be an issue with your hardware, or the OS/driver fucked something up on your system, or it could be just that series that triggers a bug in GZDoom's vulkan implementation. All the options are on the table right now and I need to rule out some of them before figuring out what to do next.