search

KhronosGroup / Vulkan-Samples

One stop solution for all Vulkan samples
Apache License 2.0
4.36k stars 651 forks source link

macOS not finding VK_MVK_macos_surface extension #190

Closed billhollings closed 3 years ago

billhollings commented 4 years ago

Installed on macOS Catalina 10.15.7, with Vulkan SDK 1.2.154.0 installed.

After cloning Vulkan-Samples with submodules, and following the build instructions, I am getting the following error when trying to run vulkan_samples hello_triangle:

[error] [framework/platform/glfw_window.cpp:39] GLFW Error (code 65542): Cocoa: Vulkan instance missing VK_MVK_macos_surface extension

Full log:

[info] Logger initialized
2020-10-16 17:15:04.393875-0400 vulkan_samples[30099:778077] Metal GPU Frame Capture Enabled
2020-10-16 17:15:04.394330-0400 vulkan_samples[30099:778077] Metal API Validation Enabled
2020-10-16 17:15:04.450674-0400 vulkan_samples[30099:778577] flock failed to lock maps file: errno = 35
2020-10-16 17:15:04.453827-0400 vulkan_samples[30099:778577] flock failed to lock maps file: errno = 35
[info] Window created
[info] Initializing vulkan instance.
[info] Enabled Validation Layers:
[info] Found GPU: AMD Radeon Pro 560
[info] Found GPU: Intel(R) HD Graphics 630
[error] [framework/platform/glfw_window.cpp:39] GLFW Error (code 65542): Cocoa: Vulkan instance missing VK_MVK_macos_surface extension
[info] Initializing vulkan device.
Program ended with exit code: 9
billhollings commented 4 years ago

I've done some poking around. It appears that one of the intervening layers is returning null for the proc address of vkCreateMacOSSurfaceMVK, even though MoltenVK is providing it. The layer seems to request the proc address as part of it's own vkCreateInstance(), but does not report it to the app when asked using vkGetInstanceProcAddr().

Am I somehow misconfiguring the layers?

abbaswasim commented 4 years ago

I can reproduce this. I don't yet know what the issue is though.

I have managed to reproduce it on macOS Catalina 10.15.7 with sdk versions vulkansdk-macos-1.2.148.1 and vulkansdk-macos-1.2.154.0 on one machine iMacPro but on another MacBook Pro with the same version of OS I can't reproduce it (not sure if that's relevant).

Having said that for some reason the Vulkan setup is wrong on the machine where it doesn't work. If I just run vulkaninfo I get a similar error as well. While on the other machines where it works. I get proper output.

$ vulkaninfo     
ERROR: [Loader Message] Code 0 : loader_get_json: Failed to open JSON file /Users/wasimabbas/macOS/share/vulkan/icd.d/MoltenVK_icd.json
ERROR at /tmp/macos-sdk-build/Vulkan-Tools/vulkaninfo/vulkaninfo.h:643:vkCreateInstance failed with ERROR_INITIALIZATION_FAILED

@billhollings can you run vulkaninfo on your machine or getting errors as well?

billhollings commented 4 years ago

can you run vulkaninfo on your machine or getting errors as well?

Using vulkansdk-macos-1.2.154.0:

Is it possible to build the samples by linking MoltenVK directly, instead of through the SDK? I expect this is a loader issue at some level, but it would be helpful to be able to bypass the loader and layers and check MoltenVK directly, if possible.

FWIW (in case it matters)...the Cube app uses the VK_EXT_metal_surface extension instead of VK_MVK_macos_surface...and of course vulkaninfo would use neither.

abbaswasim commented 4 years ago

Is it possible to build the samples by linking MoltenVK directly

I am not sure. How once does that. If it requires code/cmake changes we don't have that support. If it means just setting the right environment variables have a look at the following.

I would usually setup MoltenVK with a script like this:

#!/bin/bash

# Sets up required variables for Vulkan

SCRIPT_DIR=`dirname "$0"`
MOLTENVK_VERSION="vulkansdk-macos-1.1.154.0"
# MOLTENVK_VERSION="vulkansdk-macos-1.1.101.0"

# Path to SDK, once this is setup you can load vulkan in cmake with find_package(vulkan REQUIRED)
# Later need to link project with "Vulkan::Vulkan"
export VULKAN_SDK=$SCRIPT_DIR/LunarG-Vulkan-SDK/$MOLTENVK_VERSION/macOS
echo "Setting VULKAN_SDK=`echo $VULKAN_SDK`"

# MoltenVK framework path
export MOLTEN_VK=$SCRIPT_DIR/LunarG-Vulkan-SDK/$MOLTENVK_VERSION/MoltenVK
echo "Setting MOLTEN_VK=`echo $MOLTEN_VK`"

# Path to vulkan binaries
export PATH=$VULKAN_SDK/bin:$PATH

# Path to ICD
export VK_ICD_FILENAMES=$VULKAN_SDK/share/vulkan/icd.d/MoltenVK_icd.json
echo "Setting VK_ICD_FILENAMES=`echo $VK_ICD_FILENAMES`"

# Path to layers
export VK_LAYER_PATH=$VULKAN_SDK/share/vulkan/explicit_layer.d
echo "Setting VK_LAYER_PATH=`echo $VK_LAYER_PATH`"

# Path to Dynamic library
export DYLD_LIBRARY_PATH=$VULKAN_SDK/lib:$DYLD_LIBRARY_PATH
echo "Setting DYLD_LIBRARY_PATH=`echo $DYLD_LIBRARY_PATH`"

# Access to MoltenVK framework?
export VULKAN_FRAMEWORK_PATH=$VULKAN_SDK/Frameworks
echo "Setting VULKAN_FRAMEWORK_PATH=`echo $VULKAN_FRAMEWORK_PATH`"

# Path to Dynamic framworks
export DYLD_FRAMEWORK_PATH=$VULKAN_FRAMEWORK_PATH:$DYLD_FRAMEWORK_PATH
echo "Setting DYLD_FRAMEWORK_PATH=`echo $DYLD_FRAMEWORK_PATH`"

I am not sure however whether this is enough to hide the loader. This probably just installs the SDK manually.

Also for some reason after a few uninstall and reinstall of the Vulkan SDK. I can't reproduce it anymore :( It works on my setup now. I have tried running the hello triangle with the SDK and the the script method. In both cases it works.

gpx1000 commented 3 years ago

https://github.com/glfw/glfw/issues/1446 <-- might be related to upstream. I can verify this is working locally.

Could you investigate if

glfwinfo --list-extensions

returns a correct Vulkan loader?

abbaswasim commented 3 years ago

returns a correct Vulkan loader?

Not sure what you mean by returns correct loader but glfwinfo can find my Vulkan installation and reports the supported extensions. 

$ build/tests/glfwinfo --list-extensions
GLFW header version: 3.4.0
GLFW library version: 3.4.0
GLFW library version string: "3.4.0 Cocoa NSGL EGL OSMesa"
OpenGL context version string: "2.1 ATI-3.10.19"
OpenGL context version parsed by GLFW: 2.1.0
OpenGL context renderer string: "AMD Radeon Pro Vega 56 OpenGL Engine"
OpenGL context vendor string: "ATI Technologies Inc."
OpenGL context shading language version: "1.20"
OpenGL framebuffer:
 red: 8 green: 8 blue: 8 alpha: 8 depth: 24 stencil: 8
 samples: 0 sample buffers: 0
 accum red: 0 accum green: 0 accum blue: 0 accum alpha: 0 aux buffers: 0
OpenGL context extensions:
 GL_ARB_color_buffer_float
 [....]
Vulkan loader: available
Vulkan loader API version: 1.2
Vulkan required instance extensions: VK_KHR_surface VK_EXT_metal_surface
Vulkan instance extensions:
 VK_KHR_device_group_creation (spec version 1)
 VK_KHR_external_fence_capabilities (spec version 1)
 VK_KHR_external_memory_capabilities (spec version 1)
 VK_KHR_external_semaphore_capabilities (spec version 1)
 VK_KHR_get_physical_device_properties2 (spec version 2)
 VK_KHR_get_surface_capabilities2 (spec version 1)
 VK_KHR_surface (spec version 25)
 VK_EXT_debug_report (spec version 9)
 VK_EXT_debug_utils (spec version 2)
 VK_EXT_metal_surface (spec version 1)
 VK_EXT_swapchain_colorspace (spec version 4)
 VK_MVK_macos_surface (spec version 3)
Vulkan discrete GPU device: "AMD Radeon Pro Vega 56" (API version 1.1)
Vulkan device extensions:
 VK_KHR_16bit_storage (spec version 1)
 VK_KHR_8bit_storage (spec version 1)
 VK_KHR_bind_memory2 (spec version 1)
 VK_KHR_create_renderpass2 (spec version 1)
 VK_KHR_dedicated_allocation (spec version 3)
 VK_KHR_depth_stencil_resolve (spec version 1)
 VK_KHR_descriptor_update_template (spec version 1)
 VK_KHR_device_group (spec version 4)
 VK_KHR_driver_properties (spec version 1)
 VK_KHR_external_fence (spec version 1)
 VK_KHR_external_memory (spec version 1)
 VK_KHR_external_semaphore (spec version 1)
 VK_KHR_get_memory_requirements2 (spec version 1)
 VK_KHR_image_format_list (spec version 1)
 VK_KHR_maintenance1 (spec version 2)
 VK_KHR_maintenance2 (spec version 1)
 VK_KHR_maintenance3 (spec version 1)
 VK_KHR_multiview (spec version 1)
 VK_KHR_portability_subset (spec version 1)
 VK_KHR_push_descriptor (spec version 2)
 VK_KHR_relaxed_block_layout (spec version 1)
 VK_KHR_sampler_mirror_clamp_to_edge (spec version 3)
 VK_KHR_sampler_ycbcr_conversion (spec version 14)
 VK_KHR_shader_draw_parameters (spec version 1)
 VK_KHR_shader_float16_int8 (spec version 1)
 VK_KHR_shader_subgroup_extended_types (spec version 1)
 VK_KHR_storage_buffer_storage_class (spec version 1)
 VK_KHR_swapchain (spec version 70)
 VK_KHR_swapchain_mutable_format (spec version 1)
 VK_KHR_timeline_semaphore (spec version 2)
 VK_KHR_uniform_buffer_standard_layout (spec version 1)
 VK_KHR_variable_pointers (spec version 1)
 VK_EXT_debug_marker (spec version 4)
 VK_EXT_descriptor_indexing (spec version 2)
 VK_EXT_fragment_shader_interlock (spec version 1)
 VK_EXT_hdr_metadata (spec version 2)
 VK_EXT_host_query_reset (spec version 1)
 VK_EXT_image_robustness (spec version 1)
 VK_EXT_inline_uniform_block (spec version 1)
 VK_EXT_memory_budget (spec version 1)
 VK_EXT_private_data (spec version 1)
 VK_EXT_robustness2 (spec version 1)
 VK_EXT_scalar_block_layout (spec version 1)
 VK_EXT_shader_stencil_export (spec version 1)
 VK_EXT_shader_viewport_index_layer (spec version 1)
 VK_EXT_subgroup_size_control (spec version 2)
 VK_EXT_texel_buffer_alignment (spec version 1)
 VK_EXT_vertex_attribute_divisor (spec version 3)
 VK_AMD_gpu_shader_half_float (spec version 2)
 VK_AMD_negative_viewport_height (spec version 1)
 VK_AMD_shader_trinary_minmax (spec version 1)
 VK_INTEL_shader_integer_functions2 (spec version 1)
 VK_GOOGLE_display_timing (spec version 1)
 VK_NV_glsl_shader (spec version 1)

As you can see it reports both VK_EXT_metal_surface and VK_MVK_macos_surface and it seems like glfw prefers VK_EXT_metal_surface by looking at Vulkan required instance extensions: VK_KHR_surface VK_EXT_metal_surface line.

billhollings commented 3 years ago

I've managed to resolve this in my environment, at least.

In my environment, I had symlink'd libvulkan.dylib directly to libMoltenVK.dylib (effectively making MoltenVK the loader and only layer).

That may have been the problem in my environment. In reverting to using the real SDK 1.2.170 loading, the problem seems to have gone away. So it might be an issue within MoltenVK when it acts as loader (and which I didn't detect earlier).

@abbaswasim I don't know whether this info will affect the conditions under which you were able to replicate the issue above.

marty-johnson59 commented 3 years ago

@abbaswasim, can you advise if this issues is resolved, or is there further investigation required before closing? Thanks

gpx1000 commented 3 years ago

@marty-johnson59 I could be wrong, but I believe this issue is resolved. @abbaswasim reacted with a thumbs up to your query.

marty-johnson59 commented 3 years ago

So he did. Thanks! Closing