cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

drchat
Journeyman III

Crash in vkCreateGraphicsPipelines

Hey - I'm working on an app that uses Vulkan and AMD users are reporting that they're crashing deep in driver code when trying to compile certain shaders.

This same code works without problem on NVIDIA drivers, making it difficult for me to debug myself.

Attached is a crash dump provided by a user. Can someone lead me in the right direction?

0 Likes
1 Solution

There's two problems about the fragment shader:

150:    9(fvec4) VectorShuffle 147(gl_FragCoord) 149(gl_PointCoord) 0 1 4 5

Please note that 147 and 149 are pointer, so they must be loaded first. Should be changed to something like this:

226:    9(fvec4) Load 147(gl_FragCoord)

227:    7(fvec2) Load 149(PointCoord)

150:    9(fvec4) VectorShuffle 226 227 0 1 4 5

Then we have:

175:    3(float) CompositeExtract 108(push_consts) 2 0

176:    3(float) CompositeExtract 108(push_consts) 2 1

177:    3(float) CompositeExtract 108(push_consts) 2 2

Similar case here. 108 is a pointer so should be loaded first.

228:   106(push_consts_type) Load 108(push_consts)

175:    3(float) CompositeExtract 228 2 0

176:    3(float) CompositeExtract 228 2 1

177:    3(float) CompositeExtract 228 2 2

View solution in original post

0 Likes
22 Replies
dwitczak
Staff

Thank you for your report. Can you post the shader code / attach the SPIR-V blob here, or perhaps e-mail it to me? What was the version of the driver that the user was using?

0 Likes

I've attached a SPIR-V blob of another shader (which isn't the exact one in the attached dump, but should still trigger the same crash). The user was using the latest driver version as of that date (16.6.1).

0 Likes

Taking this internally. Will get back to you as soon as I hear back from the relevant team.

0 Likes

The shader requires a GenericPointer capability which Vulkan implementations are not required to support. Our feeling is that the SPIR-V blob may have been generated using a third-party vendor's tool which appears to generate non-portable SPIR-V binaries.

Please use the official Khronos compiler called glslang to convert GLSL shaders to SPIR-V. You can find it here: GitHub - KhronosGroup/glslang: Khronos reference front-end for GLSL and ESSL, and sample SPIR-V gene... .

0 Likes

We're generating shaders ourselves, and we don't actually use that capability so it can be removed. Is that what was causing the crash?

0 Likes

It is OpenCL-specific, so yes, indeed.

0 Likes

Okay - according to our users they're still having crashes. Updated OP with new files.

0 Likes

OK, will get back to you on Monday on this.

The vertex binary has the following code:

161:   10(bvec4) CompositeConstruct 160 160 160 160

162:    7(fvec3) Load 129(vf0_0)

164:    7(fvec3) Select 161 162 163

The condition 161 is a “bvec4” type while the source and destination 164, 162, 163 are “fvec3” types. The component counts are not identical. This violates the SPIR-V spec:

Condition must be a scalar or vector of Boolean type. It must have the same number of components as Result Type.

The fragment binary, on the other hand, contains the following code:

153:     2(bool)   IEqual 143 136

154:    8(fvec4)   Load 152

155:    8(fvec4)   Select 153 147 154

The root cause is the same. 153 is a Boolean scalar while 155, 147, 154 are all “fvec4” types.

The geometry shader is fine.

Please consider using the spirv-validator tool available under https://github.com/KhronosGroup/SPIRV-Toolsto capture similar issues in the future.

0 Likes

Blah - thanks. Downside to writing this by hand is I make a lot of mistakes . We need to update our copy of the validator.

Sephiroth99 is describing the same thing as me, so he should be good to go as well.

Edit: Okay - the validator isn't reporting errors like these for us. How did you catch these errors?

0 Likes

Manual verification. However, if issues like these are not captured by the tool, you may want to consider filing a bug/feature request at the project's site. After all, aim of that project is to help developers quickly identify problems with SPIR-V shaders.

0 Likes

I have the problem on my system (HD 7950, Crimson 16.6.1).

I don't know if this could help: the pipeline has 3 stages (vert, geom and frag). The vert and frag shaders are generated as SPIR-V shaders (as mentionned by drchat), and the geom is pre generated from a GLSL shader (see: xenia/src/xenia/gpu/vulkan/shaders at master · benvanik/xenia · GitHub ) compiled using standard tools, which is then embedded as code in the program and loaded as-is in the pipeline.

Attached is a set of 3 SPIR-V shaders used in a call to vkCreateGraphicsPipelines (vert and frag are in binary format, geom in text format). Geom is the rect_list shader in the previous link.

Let me know if you need more info.

Thanks!

0 Likes

Thank you for your report. Will have a look into this on Monday as well!

0 Likes

Can you provide a binary form of the geometry shader as well? This is to ensure we use the same binaries on our end as you do.

0 Likes

Hi dwitczak,

Just to clarify, I am using the same program as drchat (xenia). Initially my message was to bring attention to the fact that the pipeline has 3 stages.

The review of the shaders did not fix the crash issue unfortunately, although I am sure it did help!

See attached for new set of shaders. These new shaders are generated with the fixes drchat implemented following the first review of the shaders. The geometry shader is still the same though, but it is now in binary format as requested.

If needed I can also provide a minidump of the application state right before it crashes in the driver, if it could help.

And to follow up to your answer to drchat about the validator, I guess we need to do a round of manual validation on xenia's shader translator/generator.

0 Likes

We will have a look at this shortly. Won't need the mini-dump at this point.

0 Likes

There's two problems about the fragment shader:

150:    9(fvec4) VectorShuffle 147(gl_FragCoord) 149(gl_PointCoord) 0 1 4 5

Please note that 147 and 149 are pointer, so they must be loaded first. Should be changed to something like this:

226:    9(fvec4) Load 147(gl_FragCoord)

227:    7(fvec2) Load 149(PointCoord)

150:    9(fvec4) VectorShuffle 226 227 0 1 4 5

Then we have:

175:    3(float) CompositeExtract 108(push_consts) 2 0

176:    3(float) CompositeExtract 108(push_consts) 2 1

177:    3(float) CompositeExtract 108(push_consts) 2 2

Similar case here. 108 is a pointer so should be loaded first.

228:   106(push_consts_type) Load 108(push_consts)

175:    3(float) CompositeExtract 228 2 0

176:    3(float) CompositeExtract 228 2 1

177:    3(float) CompositeExtract 228 2 2

0 Likes

Huh - I really wish NVIDIA would throw errors instead of silently ignoring these issues.

Could you guys make the driver return an error code if it encounters a shader that violates spec, so we can dump the shader into the log file?

0 Likes

Vulkan's rule number one is that everything the app tells the driver to do is guaranteed to make sense and therefore needs no validation (excepts the requirements, subtly summarized in the "Valid Usage" sections"). Any behavior which does not adhere to that rule if free to cause undefined behavior, including a process crash. This naturally also applies to shaders that application submits to the driver.

Since validation comes at a performance cost, it is external tools which should be used at development time. SPIR-V Validator is what we recommend ISVs to use. Now, I understand the coverage of that tool is not perfect yet, but it's an open-source project and the community is welcome to contribute. Please consider committing some time to contribute patch proposals to that project, so that all Vulkan developers can benefit in the long run.

0 Likes

Alrighty - that makes sense. How are you formatting the assembly so you can see the types of each ID?

And thanks for your help, really appreciate it.

0 Likes

Manual work, again..

0 Likes

Hah - well thanks for your help.

Crashes are fixed, now I just need to figure out why AMD cards display a black screen in Xenia

0 Likes