Unexpected Crash (caused by shader)

📚 Official Books Metal by Tutorials
1

I’m in Chapter 12 (near the end) and all of a sudden, I started crashing, stopping
at Model.Render.drawIndexedPrimitives. I tracked it down to some code in
Fragment.metal. I put some extra code in to try and target the “crash”, specifically
just paint everything orange.

The area is where I just added stuff about using the IdTexture.

The following is the code which does NOT crash

material.baseColor = vector_float3(0.9, 0.5, 0.0);
if (!is_null_texture(idTexture)) {
    material.baseColor = vector_float3(0.9, 0.5, 0.0);
}

The following is the code which does crash

// material.baseColor = vector_float3(0.9, 0.5, 0.0);
if (!is_null_texture(idTexture)) {
material.baseColor = vector_float3(0.9, 0.5, 0.0);
}

All I’ve done is comment out the material.baseColor assignment.

Anyone have any idea why this is crashing? I could move to another Xcode
(currently running Version 16.0 (16A242d)) as I see a 16.1 (Beta 2 16B5014f),
but I’m not sure that’ll solve my issue (and then, I’m an old coder so I’m a little
adverse to “beta” anything).

Of course, I’m open to the fact that I’m just doing something really dumb.

2

Ok, finally figured it out.
Issue was due to the fact that the texture was mis-cast (texture2d.float and NOT texture2d.uint. Apparently, ‘is_null_texture’ does more than check if the texture argument is nil, but also does some validity (probably type) checks on texture itself, and if it doesn’t like it, boom.
Sorry to waste your time with, yet another, fat-finger problem.

However, that brings up a thing that’s been bugging me - how to effectively debug shaders. I’m only on Ch 12 of your book, and I do know you chatted about using the GPU workload capture, but maybe later on, you folks chat about a more effective way of debugging shader code itself? Or, even, some chat about “here’s what happens when if/when your shader crashes and what to do to help debug it”. Just a thought. Thanks

1 Like