ZDoom

by **Graf Zahl** » Wed May 15, 2019 3: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.

by **MasterBeavis** » Wed May 15, 2019 4: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 all • Expand 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.

by **Graf Zahl** » Thu May 16, 2019 12: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.

by **dpJudas** » Thu May 16, 2019 5: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.

by **Graf Zahl** » Thu May 16, 2019 6:09 am

And let me take one guess: VkImage of course does not have a query function for this, correct?

by **dpJudas** » Thu May 16, 2019 6: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.

by **MasterBeavis** » Thu May 16, 2019 8: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 all • Expand 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

by **dpJudas** » Thu May 16, 2019 8: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.

by **MasterBeavis** » Thu May 16, 2019 9: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

by **_mental_** » Thu May 16, 2019 9: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.

by **MasterBeavis** » Thu May 16, 2019 9:25 am

https://ci.appveyor.com/project/coelcke ... tnvn8nr2cg this one

by **_mental_** » Thu May 16, 2019 9: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.

by **MasterBeavis** » Thu May 16, 2019 4: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?

by **MasterBeavis** » Sat May 18, 2019 12: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

by **MasterBeavis** » Fri Jun 07, 2019 9: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

ZDoom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Who is online