[Fixed] [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series"

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby Graf Zahl » Wed May 15, 2019 4:49 pm

Actually quite simple.

- Install the SDK.
- Run GZDoom
- Type 'vk_debug 1' at the console
- Quit GZDoom.
- Start it again and play until it crashes.

The SDK contains some validation layers that can output diagnostic messages to the console and the hope is that there may be one shortly before the crash that gives some hint what's wrong.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby MasterBeavis » Wed May 15, 2019 5:05 pm

Graf Zahl wrote:Actually quite simple.

- Install the SDK.
- Run GZDoom
- Type 'vk_debug 1' at the console
- Quit GZDoom.
- Start it again and play until it crashes.

The SDK contains some validation layers that can output diagnostic messages to the console and the hope is that there may be one shortly before the crash that gives some hint what's wrong.

im unable to repro a crash after doing this

crashes have just stopped after installing the SDK not sure what this means

I am getting vulkan warnings though in console about so and so not consumed by vertex shader or fragment shader


When VK_debug 1 is turnned on i get no crashes but if its off i get crashes


Edit. ok here it is. anytime these warnings happen thats when the game crashes without debug

Code: Select allExpand view
Log started: 2019-05-16 00:13:08

----------------------------------------

E1M2 - Nuclear Plant

Bullets
Bullets
Bullets

----------------------------------------
2/5 Demons Killed:
+60
----------------------------------------
Bullets
Bullets
Bullets
Bullets
Bullets
Bullets
Bullets
Health bonus
Medium Armor Chunk
Medikit
----------------------------------------

----------------------------------------

----------------------------------------
Secret found
+100
----------------------------------------
Medikit
Health bonus
Health bonus

[vulkan warning] Vertex attribute at location 3 not consumed by vertex shader
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart


[vulkan warning] Vertex attribute at location 4 not consumed by vertex shader
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart


[vulkan warning] Vertex attribute at location 5 not consumed by vertex shader
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart


[vulkan warning] vertex shader writes to output location 0.0 which is not consumed by fragment shader
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart


[vulkan warning] vertex shader writes to output location 1.0 which is not consumed by fragment shader
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart

Bullets
Health bonus
Health bonus
Health bonus
Carrion
Bullets
Bullets
Chainsaw. Shred and shear!
Carrion

----------------------------------------
3/5 Demons Killed:
+90
----------------------------------------
Carrion
Bullets
Carrion
Bullets
Bullets
Carrion
Health bonus
Bullets
Carrion
Carrion
Carrion
Health bonus
Carrion
Stimpack
Stimpack
Carrion
Stimpack
Carrion
Carrion
Health bonus
Stimpack
Carrion
Carrion
Stimpack
Carrion
Stimpack
Stimpack
Stimpack
Carrion
Stimpack
Stimpack
Carrion
Health bonus
----------------------------------------

----------------------------------------
Frag Grenade equipment
Picked up a backpack

----------------------------------------
Secret found
+100
----------------------------------------
Health bonus
Health bonus
Health bonus

----------------------------------------
4/5 Demons Killed:
+120
----------------------------------------
Carrion
Stimpack
Stimpack
Carrion
Carrion
Carrion
Health bonus
Health bonus
Health bonus
----------------------------------------

----------------------------------------
Health bonus

----------------------------------------
Secret found
+100
----------------------------------------
Carrion
Health bonus
Carrion
Chainsaw fuel
Stimpack
Carrion
Stimpack
Stimpack
Stimpack
CAPTON BADASS was burned by an imp.

----------------------------------------

E1M2 - Nuclear Plant

Bullets
Bullets
Bullets

----------------------------------------
2/5 Demons Killed:
+60
----------------------------------------
Bullets
Bullets
Bullets
Bullets
Bullets
Bullets
Bullets
Health bonus
Carrion
Bullets
Game saved.
Bullets
Stimpack
Stimpack
Carrion
Bullets
Bullets
Stimpack
Carrion
Stimpack
Carrion
Carrion
Stimpack
Carrion
Health bonus

----------------------------------------
3/5 Demons Killed:
+90
----------------------------------------
Carrion
Carrion
Stimpack
Stimpack
Carrion

[vulkan error] vkCmdResolveImage(): Cannot use image 0xd4[VkRenderBuffers.SceneColor] (layer=0 mip=0) with specific layout VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL that doesn't match the previous known 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-vkCmdResolveImage-srcImageLayout-00260)
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart


[vulkan error] Submitted command buffer expects image 0xd4[VkRenderBuffers.SceneColor]  (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL.
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from vkEnumerateInstanceLayerProperties
Called from BaseThreadInitThunk
Called from RtlUserThreadStart

Game saved.
Last edited by MasterBeavis on Thu May 16, 2019 9:41 am, edited 1 time in total.
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] Vulkan Crashes "AMD 400/500 Series Tester

Postby Graf Zahl » Thu May 16, 2019 1:07 am

Those two errors near the end look like something a driver may crash on. AMD seems to be far more sensitive towards these - on NVidia the driver doesn't really care because these different image layouts do not exist technically.

I have to wonder what this means for Vulkan overall. It's apparently not possible to do proper development without a multitude of AMD drivers and GPUs.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby dpJudas » Thu May 16, 2019 6:53 am

Those errors should have been fixed by this commit. Either this was run on an exe prior to that or the fix didn't work.

The image transitions in general is truly a pain in the ass because not only does vulkan expect the application to always know which layout it has, there's also implicit transitions that can be performed as part of a render pass. That makes it more tricky to make a generalized system that tracks it on the application side.
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby Graf Zahl » Thu May 16, 2019 7:09 am

And let me take one guess: VkImage of course does not have a query function for this, correct?
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

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

It doesn't because of the async nature of vulkan. Notice on the error message how the validation layer doesn't know there's a problem until the command buffer is submitted. Because many of those could be in flight the data is not available.

Overall I can try make the transition tracking a little bit more resilient than it is right now, but ultimately any image layout tracker will always be a little messy.
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby MasterBeavis » Thu May 16, 2019 9:40 am

dpJudas wrote:It doesn't because of the async nature of vulkan. Notice on the error message how the validation layer doesn't know there's a problem until the command buffer is submitted. Because many of those could be in flight the data is not available.

Overall I can try make the transition tracking a little bit more resilient than it is right now, but ultimately any image layout tracker will always be a little messy.


this log was made with 4.1.2 so no that fix isnt there but the fix istelf doesnt stop the crashes it just gets rid of those messages you still get a ton of

Code: Select allExpand view
[vulkan warning] Vertex attribute at location x not consumed by vertex shader
[vulkan warning] vertex shader writes to output location 0.0 which is not consumed by fragment shader


these errors though in the nightly. im curious why i dont get complete crashes with debug enabled though and just messages while the game runs fine
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] Vulkan Crashes "AMD 400/500 Series Tester

Postby dpJudas » Thu May 16, 2019 9:56 am

The errors Graf was commenting on are expected on 4.1.2 (the fix can't magically be backported). If those errors go away with a newer build then that means it isn't (lack of) image transitions that is causing the crash.

Those vertex attribute things are warnings, not errors. They report an inefficiency in how vertex attributes are read from vertex buffers and how the vertex shader transfers outputs to the fragment shader inputs. They are relatively harmless and does not explain any crashes. The only reason the validation layer reports them is because they mean the vertex shader is doing work that the fragment shader never uses.
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby MasterBeavis » Thu May 16, 2019 10:02 am

dpJudas wrote:The errors Graf was commenting on are expected on 4.1.2 (the fix can't magically be backported). If those errors go away with a newer build then that means it isn't (lack of) image transitions that is causing the crash.

Those vertex attribute things are warnings, not errors. They report an inefficiency in how vertex attributes are read from vertex buffers and how the vertex shader transfers outputs to the fragment shader inputs. They are relatively harmless and does not explain any crashes. The only reason the validation layer reports them is because they mean the vertex shader is doing work that the fragment shader never uses.

well using the nightly from Appvoyer i still get crashes. but when I enable debug.... the game continues to play fine in any situation were it would already have crashed i tried and tried to repro a crash with debug on but i couldnt manage it. but as soon as debug is off the crashes return as normal
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] Vulkan Crashes "AMD 400/500 Series Tester

Postby _mental_ » Thu May 16, 2019 10:10 am

Could you please be more specific and post exact version information (or link where you downloaded it)? Maybe it's only for me, but 'the nightly from Appvoyer' doesn't tell me anything.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby MasterBeavis » Thu May 16, 2019 10:25 am

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] Vulkan Crashes "AMD 400/500 Series Tester

Postby _mental_ » Thu May 16, 2019 10:36 am

OK, that's the right one. It was built with Visual Studio 2015, but I doubt this has any effect on the given crash.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom 4.1.2] Vulkan Crashes "AMD 400/500 Series Tester

Postby MasterBeavis » Thu May 16, 2019 5:18 pm

https://ci.appveyor.com/project/coelcke ... kqwy48fjyd tried it but crashes still happen unless debug is enabled

just a question but im willing to do what i need to debug this is there anything i could use to debug this outside GZDooms own debugger since i cant repro with it on?
Attachments
CrashReport.zip
(118.72 KiB) Downloaded 12 times
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] Vulkan Crashes "AMD 400/500 Series"

Postby MasterBeavis » Sat May 18, 2019 1:33 am

I think the crash might have been somthing to do with old options in the INI cause after restarting all seems well

After some fiddling ive narrowed it down Post-Processing is causing crashes
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] Vulkan Crashes "AMD 400/500 Series"

Postby MasterBeavis » Fri Jun 07, 2019 10:47 pm

interesting new find.

https://ci.appveyor.com/project/coelcke ... /artifacts
this build crashes

https://ci.appveyor.com/project/coelcke ... /artifacts
This build does not crash

seems to be a bug in the 64bit build
User avatar
MasterBeavis
 
Joined: 13 May 2019
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

PreviousNext

Return to Closed Bugs

Who is online

Users browsing this forum: Semrush [Bot] and 0 guests