Gfx: MTLIGAccelBuffer addDebugMarker:range:]: unrecognized selector

[edap]

I receive this error message:

   Compiling wgpu v0.4.0 (/Users/da1/Sources/rust/wgpu-rs)
    Finished dev [unoptimized + debuginfo] target(s) in 6.35s
     Running `target/debug/examples/cube`
2019-11-25 14:56:16.620 cube[16426:135436] -[MTLIGAccelBuffer addDebugMarker:range:]: unrecognized selector sent to instance 0x7fdfe35a14c0
[2019-11-25T13:56:16Z ERROR relevant] Values of this type can't be dropped!
[1]    16426 segmentation fault  cargo run --example cube

when running the cube example or the skybox one.

I am on Mac OS "El Capitan", MacBook Pro (Retina, 13-inch, Mid 2014).
GPU Intel Iris 1536 MB.

[kvark]

We seem to be missing a check for addDebugMarker selector to be supported.

[dyaso]

What's the proper way to fix this, to test if addDebugMarker is allowed?

Failing that, how can i get wgpu to use a modified version of this crate with the calls to add_debug_marker commented out?

[grovesNL]

@counterfactual-regret-minimization we could add a field like supports_debug_markers: bool to PrivateCapabilities.

supports_debug_marker should be true or false based on whether the macOS or iOS/tvOS versions meet the minimum requirements for the addDebugMarker API (see the right pane), so something like:

supports_debug_markers: if is_mac {
        caps.has_version_at_least(10, 12)
    } else {
        caps.has_version_at_least(10, 0)
    }

Then whenever we use add_debug_marker we could check caps.supports_debug_markers first.

[dyaso]

Did that, now the device.rs line 119 assertion platform does not support specialization panics.

I don't know what that does, but putting another self.shared.private_caps.supports_debug_markers check around the assertion lets the quad example work.

Are you sure those are the right version numbers? It says "macOS 10.12+", which i'd interpret to mean 10.12 or higher, and where does the major version 11 come from for non-macOS OSes?

[grovesNL]

Oops, you're right – I meant to write (10, 12) for macOS and (10, 0) for iOS+tvOS 😄

Fixing the specialization issue fully will take some more work. The idea here is that we have a default value for some variable in our shader (say x = 3) and later change this constant (x = 4) just before we use it. This creates a "specialized" shader where x is always 4.

On Metal we specialize functions by using MTLFunctionConstantValues. Unfortunately this feature is only available on macOS 10.12+ and iOS/tvOS 10.0+ (already included in PrivateCapabilities as caps.function_specialization). If we disable the assertion then we'll fallback to the default value (x = 3). So in order to fully fix the specialization issue for macOS <10.12 or iOS/tvOS < 10.0 we'll need to specialize shaders in another way:

• One possibility is to update the shader source directly when we generate MSL with spirv_cross. If you're interested in looking into this, please let me know and I can help you
• A workaround for now is to simply disable the assertion for now which will use the default value for specialization constants (e.g. x = 3 from the example above), and instead log an error message (with error!). We don't really use specialization constants in wgpu-rs so the error! logging might be sufficient if that's what you're interested in.

[dyaso]

Yeah, i'm just trying to get wgpu working on my oldish macbook, and unfortunately don't know anything about spirv_cross or MSL.

Would an error message like error!("Shader constants not specialized, using default values: {:?}", specialization); be ok?

[kvark]

wgpu doesn't use specialization, so it shouldn't be a blocker for you