Is it intended behavior that the Vulkan SDK is needed to compile any Rust code in debug mode that has ash as a dependency?

[ctrlcctrlv]

See MFEK/glif#229, discovered by @eliheuer.

When compiling an application with an ash dependency via rafx-api, it panics at Unable to load create_debug_utils_messenger_ext unless compiled in release mode.

[Ralith]

The issue you link appears to be complaining about a runtime error, not a compiletime error. ash does not automatically call any Vulkan functions or automatically load any Vulkan extensions or layers; if your application is failing because it can't find an extension or layer, it is due to code downstream of ash.

[ctrlcctrlv]

Thank you very much. I believed that ash was the problem due to my finding this:

https://github.com/MaikKlein/ash/blob/762666783a363aa46e4e73663ed5d67f461970a3/ash/Cargo.toml#L20-L21

I noticed ExtDebugUtilsFn, which actually seems to do the loading of system function create_debug_utils_messenger_ext. You are saying then that @aclysma's rafx actually is the one "deciding" whether or not to load validation layers, and not ash? Because @aclysma removed the old Skulpin function use_vulkan_debug_layer, so now I'm just trying to figure out where responsibility has bubbled up to, and tried ash first as it seemed to have promising references to debug and libloading in its Cargo.toml.

[ctrlcctrlv]

And, as to what I'm trying to achieve, all I'd like to be able to do is move Vulkan SDK dependency behind a build flag in MFEKglif, so I'd just like to be able to provide something to say "please don't use Vulkan's debug layers for this build", as most of what goes wrong and needs debugging in MFEKglif has nothing to do with Vulkan—although I was critical of @aclysma's changes at the time, which eliminated many features (including this debug layer enable builder API,) turns out he was actually smart to make them, as Skulpin/Vulkan has receded from view as a frequent source of bugs for me…it's the most stable part of MFEKglif of late to be honest.

[MarijnS95]

You should edit the issue description to contain a short summary of the issue faced here, instead of pointing readers to an off-project issue/comment that mentions a "second error" which appears to be a screenshot of an unwrap() on a None value deep down in your/MFEK code.

[ctrlcctrlv]

@MarijnS95 My apologies, done. :)

[MarijnS95]

I believed that ash was the problem due to my finding this:

The top screenshot of this issue shows Ash 0.32.1 being in use, where none of those linking features exist yet. Runtime loading is the default (and has little/no impact on the layers, except from the SDK shipping both the linking libraries necessary in addition to the validation layers).

https://github.com/MaikKlein/ash/blob/d044ae5dda640feee7e88003b52da2fc3085bd97/ash/Cargo.toml#L13-L17

FWIW these features only change the way the entrypoint - vkGetInstanceProcAddr - is loaded. All the rest, including the debug functions that are lazily loaded whenever DebugUtils::new(&entry, &instance) / vk::ExtDebugUtilsFn::load(|name| ...) will be loaded the same regardless. Sounds like you're hitting a conditional elsewhere.

[ctrlcctrlv]

I see, I think I should open this against aclysma/rafx then, looking through the code there, I see this:

https://github.com/aclysma/rafx/blob/056d01667cf94481f922b9c7e3c8bdf9542c9355/rafx-api/src/types/misc.rs#L25-L34

impl Default for RafxValidationMode {
    fn default() -> Self {
        #[cfg(debug_assertions)]
        let validation_mode = RafxValidationMode::EnabledIfAvailable;
        #[cfg(not(debug_assertions))]
        let validation_mode = RafxValidationMode::Disabled;

        validation_mode
    }
}

If I follow that back all the way I do see that this is what's causing the issue here. Thank you! Sorry I did not understand too well boundary between ash and rafx, my bad.