aclysma / rafx

Multi-backend renderer with asset pipeline. The objective of this repo is to build a scalable, flexible, data driven renderer.
Apache License 2.0
640 stars 32 forks source link

Panic: Unable to load create_debug_utils_messenger_ext #180

Closed liquidev closed 3 months ago

liquidev commented 3 years ago

This happened to me when I was trying to use skulpin on Linux, GNOME 3.38 (Wayland).

thread 'main' panicked at 'Unable to load create_debug_utils_messenger_ext', /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.32.0/src/vk/extensions.rs:10475:21
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/25b764849625cb090e8b81d12d2bb2295d073788/library/std/src/panicking.rs:543:12
   1: ash::vk::extensions::ExtDebugUtilsFn::load::create_debug_utils_messenger_ext
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.32.0/src/vk/extensions.rs:10475:21
   2: ash::vk::extensions::ExtDebugUtilsFn::create_debug_utils_messenger_ext
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.32.0/src/vk/extensions.rs:10599:9
   3: ash::extensions::ext::debug_utils::DebugUtils::create_debug_utils_messenger
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.32.0/src/extensions/ext/debug_utils.rs:109:9
   4: rafx_api::backends::vulkan::internal::instance::VkInstance::setup_vulkan_debug_callback
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/rafx-api-0.0.13/src/backends/vulkan/internal/instance.rs:229:22
   5: rafx_api::backends::vulkan::internal::instance::VkInstance::new
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/rafx-api-0.0.13/src/backends/vulkan/internal/instance.rs:167:18
   6: rafx_api::backends::vulkan::api::RafxApiVulkan::new
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/rafx-api-0.0.13/src/backends/vulkan/api.rs:114:24
   7: rafx_api::api::RafxApi::new_vulkan
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/rafx-api-0.0.13/src/api.rs:103:24
   8: rafx_api::api::RafxApi::new
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/rafx-api-0.0.13/src/api.rs:74:20
   9: skulpin_renderer::renderer::Renderer::new
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-renderer-0.14.0/src/renderer.rs:119:28
  10: skulpin_renderer::renderer::RendererBuilder::build
             at /home/daknus/.cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-renderer-0.14.0/src/renderer.rs:53:9
  11: netcanv::main
             at ./src/main.rs:43:24
  12: core::ops::function::FnOnce::call_once
             at /rustc/25b764849625cb090e8b81d12d2bb2295d073788/library/core/src/ops/function.rs:227:5
aclysma commented 3 years ago

Did you install the vulkan sdk? You could also try running without the vulkan debug layers.

liquidev commented 3 years ago

How do I disable the vulkan debug layers? I've browsed some source code, and as far as I can tell they are only disabled in release mode.

aclysma commented 3 years ago

I thought this was exposed as an option in the skulpin layers, but I think that code didn't survive the transition to using rafx.

You can change initialization of rafx here: https://github.com/aclysma/skulpin/blob/73f6ad4c2f88caceda9d548fa895d53f60fc4ee2/skulpin-renderer/src/renderer.rs#L119

I would call new_vulkan() instead of new(), this value controls whether validation is enabled or not: https://github.com/aclysma/rafx/blob/b93722c32942f07de2e40a71c4d53389c3fd9a52/rafx-api/src/backends/vulkan/api.rs#L44

Another idea... you can use cargo overrides to compile upstream crates in release mode (either rafx-api specifically or all of them) https://doc.rust-lang.org/cargo/reference/profiles.html

I highly recommend installing the SDK and keeping the validation layers turned on during development.

I might add support for this (when I'm not on vacation :) ) but to be honest, I don't have any personal use for this project anymore. So I don't plan to add features, and I'll only maintain it as long as it doesn't require significant changes. So if you use this for something serious, please be prepared for the possibility that you will have to fork it.

liquidev commented 3 years ago

Sure, installing the SDK isn't a problem for me. I was just wondering if there was a way to disable the debug layers completely, as I'm not really developing things with Vulkan, only using skulpin; cargo profiles seem like the cleanest solution here.

I'm using skulpin (and thus rafx) for my app NetCanv, but since Skia is quite big and bloated I've been meaning to switch away from it, so no pressure.

ctrlcctrlv commented 2 years ago

Happened in MFEKglif just now, see https://github.com/MaikKlein/ash/issues/544, @MarijnS95 very kindly helped me figure out it was caused by rafx and not ash, and I eventually found this issue.

I'll try your workarounds tomorrow @aclysma.

Just as a comment though:

I highly recommend installing the SDK and keeping the validation layers turned on during development.

I'm not sure this is really necessary for Skulpin, especially if it's a non-maintainer compiling the code, it's been really stable lately. If someone is compiling a debug build of MFEKglif it's very very unlikely they're trying to debug a graphics issue, almost certain they're trying to debug a problem in my code hehe.

ctrlcctrlv commented 2 years ago

Also @liquidev I do have to say I disagree about Skia being "bloated"…then again it may very well be for your paint app, but I use features it provides that no other free software does on the GPU (path dashing, SVG export of canvas, path measurement, boolean operations on paths, etc). Skia seems to have been made with a font editor in mind, because I use almost the entire API, pretty much unheard of lol.

liquidev commented 2 years ago

Yeah, bloat is a relative term and I was using my little painting app as a baseline when making that comparison.