Code Monkey home page Code Monkey logo

khronosgroup / moltenvk Goto Github PK

View Code? Open in Web Editor NEW
4.6K 133.0 400.0 12.74 MB

MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.

License: Apache License 2.0

C 1.27% C++ 14.81% Shell 1.06% Objective-C 26.28% Objective-C++ 56.34% Makefile 0.20% Python 0.05%

moltenvk's Introduction

MoltenVK

MoltenVK

Copyright (c) 2015-2024 The Brenwill Workshop Ltd.

Build Status

Table of Contents

Introduction to MoltenVK

MoltenVK is a layered implementation of Vulkan 1.2 graphics and compute functionality, that is built on Apple's Metal graphics and compute framework on macOS, iOS, tvOS, and visionOS. MoltenVK allows you to use Vulkan graphics and compute functionality to develop modern, cross-platform, high-performance graphical games and applications, and to run them across many platforms, including macOS, iOS, tvOS, visionOS, Simulators, and Mac Catalyst on macOS 11.0+, and all Apple architectures, including Apple Silicon.

Metal uses a different shading language, the Metal Shading Language (MSL), than Vulkan, which uses SPIR-V. MoltenVK automatically converts your SPIR-V shaders to their MSL equivalents.

To provide Vulkan capability to the macOS, iOS, tvOS, and visionOS platforms, MoltenVK uses Apple's publicly available API's, including Metal. MoltenVK does not use any private or undocumented API calls or features, so your app will be compatible with all standard distribution channels, including Apple's App Store.

The MoltenVK runtime package contains two products:

  • MoltenVK is a implementation of an almost-complete subset of the Vulkan 1.2 graphics and compute API.

  • MoltenVKShaderConverter converts SPIR-V shader code to Metal Shading Language (MSL) shader code, and converts GLSL shader source code to SPIR-V shader code and/or Metal Shading Language (MSL) shader code. The converter is embedded in the MoltenVK runtime to automatically convert SPIR-V shaders to their MSL equivalents. In addition, both the SPIR-V and GLSL converters are packaged into a stand-alone command-line MoltenVKShaderConverter macOS tool for converting shaders at development time from the command line.

Developing Vulkan Applications for macOS, iOS, tvOS, and visionOS

Using the Vulkan SDK

The recommended method for developing a Vulkan application for macOS is to use the Vulkan SDK.

The Vulkan SDK includes a MoltenVK runtime library for macOS. Vulkan is a layered architecture that allows applications to add additional functionality without modifying the application itself. The Validation Layers included in the Vulkan SDK are an essential debugging tool for application developers because they identify inappropriate use of the Vulkan API. If you are developing a Vulkan application for macOS, it is highly recommended that you use the Vulkan SDK and the MoltenVK library included in it. Refer to the Vulkan SDK Getting Started document for more info.

Because MoltenVK supports the VK_KHR_portability_subset extension, when using the Vulkan Loader from the Vulkan SDK to run MoltenVK on macOS, the Vulkan Loader will only include MoltenVK VkPhysicalDevices in the list returned by vkEnumeratePhysicalDevices() if the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR flag is enabled in vkCreateInstance(). See the description of the VK_KHR_portability_enumeration extension in the Vulkan specification for more information about the use of the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR flag.

Using MoltenVK Directly

If you are developing a Vulkan application for iOS, tvOS, or visionOS, or are developing a Vulkan application for macOS and want to use a different version or build of the MoltenVK runtime library than provided in the macOS Vulkan SDK, you can access a pre-built MoltenVK binary library from the MoltenVK repository, by selecting a repository commit from the list, and downloading the associated MoltenVK runtime library artifact.

Finally, if you want a customized build of MoltenVK, you can follow the instructions below to create a MoltenVK runtime library by fetching and building the MoltenVK source code.

To learn how to integrate the MoltenVK runtime library into a game or application, see the MoltenVK_Runtime_UserGuide.md document in the Docs directory.

Fetching MoltenVK Source Code

To fetch MoltenVK source code, clone this MoltenVK repository, and then run the fetchDependencies script to retrieve and build several external open-source libraries on which MoltenVK relies:

  1. Ensure you have cmake and python3 installed:

     brew install cmake
     brew install python3
    

    For faster dependency builds, you can also optionally install ninja:

     brew install ninja
    
  2. Clone the MoltenVK repository:

     git clone https://github.com/KhronosGroup/MoltenVK.git
    
  3. Retrieve and build the external libraries:

     cd MoltenVK
     ./fetchDependencies [platform...]
    

When running the fetchDependencies script, you must specify one or more platforms for which to build the external libraries. The platform choices include:

--all
--macos
--ios
--iossim
--maccat
--tvos
--tvossim

You can specify multiple of these selections. The result is a single XCFramework for each external dependency library, with each XCFramework containing binaries for each of the requested platforms.

The --all selection is the same as entering all of the other platform choices, and will result in a single XCFramework for each external dependency library, with each XCFramework containing binaries for all supported platforms and simulators.

Running fetchDependencies repeatedly with different platforms will accumulate targets in the XCFramework, if the --keep-cache option is used on each invocation.

For more information about the external open-source libraries used by MoltenVK, see the ExternalRevisions/README.md document.

Building MoltenVK

During building, MoltenVK references the latest Apple SDK frameworks. To access these frameworks, and to avoid build errors, be sure to use the latest publicly available version of Xcode.

Note: Xcode 14 introduced a new static linkage model that is not compatible with previous versions of Xcode. If you link to a MoltenVK.xcframework that was built with Xcode 14 or later, also use Xcode 14 or later to link it to your app or game.

If you need to use Xcode 13 or earlier to link MoltenVK.xcframework to your app or game, first build MoltenVK with Xcode 13 or earlier.

Or, if you want to use Xcode 14 or later to build MoltenVK, in order to be able to use the latest Metal capabilities, but need to use Xcode 13 or earlier to link MoltenVK.xcframework to your app or game, first add the value -fno-objc-msgsend-selector-stubs to the OTHER_CFLAGS Xcode build setting in the MoltenVK.xcodeproj and MoltenVKShaderConverter.xcodeproj Xcode projects, build MoltenVK with Xcode 14 or later, and then link MoltenVK.xcframework to your app or game using Xcode 13 or earlier.

Once built, the MoltenVK libraries can be run on macOS, iOS, tvOS, or visionOS devices that support Metal,or on the Xcode iOS Simulator, tvOS Simulator, or visionOS Simulator.

  • The minimum runtime OS versions are indicated in the Deployment Target build settings in MoltenVK.xcodeproj.
  • Information on macOS devices that are compatible with Metal can be found in this article.
  • Information on iOS devices that are compatible with Metal can be found in this article.

Building With Xcode

The MoltenVKPackaging.xcodeproj Xcode project contains targets and schemes to build and package the entire MoltenVK runtime distribution package, or to build individual MoltenVK or MoltenVKShaderConverter components.

To build a MoltenVK runtime distribution package, suitable for testing and integrating into an app, open MoltenVKPackaging.xcodeproj in Xcode, and use one of the following Xcode Schemes, depending on whether you want a Release or Debug configuration, and whether you want to build for all platforms, or just one platform (in Release configuration):

  • MoltenVK Package
  • MoltenVK Package (Debug)
  • MoltenVK Package (macOS only)
  • MoltenVK Package (iOS only)
  • MoltenVK Package (tvOS only)
  • MoltenVK Package (visionOS only) (requires Xcode 15+)

Each of theseMoltenVKPackaging.xcodeproj Xcode project Schemes puts the resulting packages in the Package directory, creating it if necessary. This directory contains separate Release and Debug directories, holding the most recent Release and Debug builds, respectively.

Note: Due to technical limitations in the dynamic library build tools, dynamic frameworks and libraries cannot be created for the tvOS Simulator, or MacCatalyst platforms. Static frameworks are created for these, and all other, platforms.

A separate Latest directory links to the most recent build, regardless of whether it was a Release or Debug build. Effectively, the Package/Latest directory points to whichever of the Package/Release or Package/Debug directories was most recently updated.

With this packaging structure, you can follow the instructions below to link your application to the MoltenVK libraries and frameworks in the Package/Latest directory, to provide the flexibility to test your app with either a Debug build, or a higher-performance Release build.

Building From the Command Line

If you prefer to build MoltenVK from the command line, or to include the activity in a larger build script, you can do so by executing a command similar to the following command within the MoltenVK repository folder, and identifying one of the Xcode Schemes from the list above. For example, the following command will build MoltenVK in the Debug configuration for macOS only:

xcodebuild build -quiet -project MoltenVKPackaging.xcodeproj -scheme "MoltenVK Package (macOS only)" -configuration "Debug"

Alternately, you can use the basic Makefile in the MoltenVK repository folder to build MoltenVK from the command line. The following make targets are provided:

make
make all
make macos
make ios
make iossim
make maccat
make tvos
make tvossim

make all-debug
make macos-debug
make ios-debug
make iossim-debug
make maccat-debug
make tvos-debug
make tvossim-debug

make clean
make install
  • Running make repeatedly with different targets will accumulate binaries for these different targets.
  • The all target executes all platform targets.
  • The all target is the default target. Running make with no arguments is the same as running make all.
  • The *-debug targets build the binaries using the Debug configuration.
  • The install target will copy the most recently built Package/Latest/MoltenVK/dynamic/dylib/macOS/libMoltenVK.dylib into the /usr/local/lib system directory on your computer. Since /usr/local/lib is protected, you will generally need to run it as sudo make install and enter your password. The install target does not build MoltenVK, and you need to run make macos or make macos-debug first.

The make targets all require that Xcode is installed on your system.

Note: Due to technical limitations within Xcode, a dynamic framework is not created for the MacCatalyst platform.

Building from the command line creates the same Package folder structure described above when building from within Xcode.

When building from the command line, you can set any of the build settings documented in the MoltenVK_Configuration_Parameters.md file, by passing them in the command line, as in the following examples:

make MVK_CONFIG_LOG_LEVEL=0

or

make macos MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS=2

...etc.

Hiding Vulkan API Symbols

You can optionally build MoltenVK with the Vulkan API static call symbols (vk*) hidden, to avoid library linking conflicts when statically bound to a Vulkan loader that also exports identical symbols.

To do so, when building MoltenVK, set the build setting MVK_HIDE_VULKAN_SYMBOLS=1. This build setting can be set in the MoltenVK.xcodeproj Xcode project, or it can be included in any of the make command-line build commands mentioned above.

With MVK_HIDE_VULKAN_SYMBOLS=1, the Vulkan vkGetInstanceProcAddr() call remains statically bound, to provide the application with the ability to retrieve the remaining Vulkan API calls as function pointers.

Accessing Metal Private API Calls

You can optionally build MoltenVK with access to private Metal API calls, also known as "Service Provider Interfaces" (SPIs). Doing so will allow MoltenVK to extend its functionality by using certain private Metal API calls, but it will also disqualify the app from being distributed via Apple App Stores.

To do so, when building MoltenVK, set the build setting MVK_USE_METAL_PRIVATE_API=1. This build setting can be set in the MoltenVK.xcodeproj Xcode project, or it can be included in any of the make command-line build commands mentioned above.

Functionality added with MVK_USE_METAL_PRIVATE_API enabled includes:

  • VkPhysicalDeviceFeatures::wideLines
  • VkPhysicalDeviceFeatures::logicOp
  • VkPhysicalDeviceFeatures::depthBounds (requires an AMD GPU)
  • VkPhysicalDevicePortabilitySubsetFeaturesKHR::samplerMipLodBias
  • VkGraphicsPipelineRasterizationCreateInfo::sampleMask, using MTLRenderPipelineDescriptor.sampleMask instead of emulating it in the fragment shader

Install MoltenVK to Replace the Vulkan SDK libMoltenVK.dylib

To replace the version of the MoltenVK installed on macOS via the Vulkan SDK standard install process, perform the following steps:

  1. Build a macOS version of MoltenVK, as described above. The default config for command-line MoltenVK build has verbose logging info turned on. If you want MoltenVK to log like the original Vulkan SDK install, use this command when building MoltenVK:

    $ make macos MVK_CONFIG_LOG_LEVEL=1
  2. From a command line terminal, execute the following command:

    $ sudo make install

This will copy your latest macOS build of MoltenVK into /usr/local/lib/libMoltenVK.dylib, overwriting the file installed by the Vulkan SDK install process.

Running MoltenVK Demo Applications

Once you have compiled and built the MoltenVK runtime distribution package from this MoltenVK repository, as described in the Building MoltenVK section, you can explore how MoltenVK provides Vulkan support on macOS, iOS, and tvOS by investigating and running the demo application that is included in MoltenVK.

The MoltenVK Cube demo app is located in the Demos folder. The demo app is available as an Xcode project. To review and run the included demo app, open the Demos/Demos.xcworkspace workspace in Xcode.

Please read the Demos/README.md document for a description and instructions for running the included Cube demo app, and for external links to more sophisticated demo applications that can be run on MoltenVK.

Using MoltenVK in Your Application

Once you have compiled and built the MoltenVK runtime distribution package from this MoltenVK repository, as described in the Building MoltenVK section, follow the instructions in the Installation section of the Docs/MoltenVK_Runtime_UserGuide.md document in the Docs directory, to link the MoltenVK libraries and frameworks to your application.

The runtime distribution package in the Package/Latest directory is a stand-alone package, and you can copy the contents of that directory out of this MoltenVK repository into your own application building environment.

MoltenVK and Vulkan Compliance

MoltenVK is designed to be an implementation of a Vulkan 1.2 subset that runs on macOS, iOS, tvOS, and visionOS platforms by mapping Vulkan capability to native Metal capability.

The fundamental design and development goal of MoltenVK is to provide this capability in a way that is both maximally compliant with the Vulkan 1.2 specification, and maximally performant.

Such compliance and performance is inherently affected by the capability available through Metal, as the native graphics driver on macOS, iOS, tvOS, and visionOS platforms. Vulkan compliance may fall into one of the following categories:

  • Direct mapping between Vulkan capabilities and Metal capabilities. Within MoltenVK, the vast majority of Vulkan capability is the result of this type of direct mapping.

  • Synthesized compliance through alternate implementation. A small amount of capability is provided using this mechanism, such as via an extra render or compute shader stage.

  • Non-compliance. This appears where the capabilities of Vulkan and Metal are sufficiently different, that there is no practical, or reasonably performant, mechanism to implement a Vulkan capability in Metal. Because of design differences between Vulkan and Metal, a very small amount of capability falls into this category, and at present MoltenVK is not fully compliant with the Vulkan specification. A list of known limitations is documented in the MoltenVK_Runtime_UserGuide.md document in the Docs directory.

The MoltenVK development team welcomes you to post Issues of non-compliance, and engage in discussions about how compliance can be improved, and non-compliant features can be implemented or worked around.

MoltenVK is a key component of the Khronos Vulkan Portability Initiative, whose intention is to provide specifications, resources, and tools to allow developers to understand and design their Vulkan apps for maximum cross-platform compatibility and portability, including on platforms, such as macOS, iOS, tvOS, and visionOS, where a native Vulkan driver is not available.

Getting Support

  • If you have a question about using MoltenVK, you can ask it in MoltenVK Discussions. This forum is monitored by MoltenVK contributors and users.

  • If you encounter an issue with the behavior of MoltenVK, or want to request an enhancement, you can report it in the MoltenVK Issues List.

  • If you encounter an issue with the Vulkan SDK, including the Validation Layers, you can report it in the Vulkan SDK Issues List.

  • If you explore MoltenVK and determine that it does not meet your requirements at this time, we would appreciate hearing why that is so, in MoltenVK Discussions. The goal of MoltenVK is to increase the value of Vulkan as a true cross-platform ecosystem, by providing Vulkan on Apple platforms. Hearing why this is currently not working for you will help us in that goal.

Contributing to MoltenVK Development

As a public open-source project, MoltenVK benefits from code contributions from a wide range of developers, and we encourage you to get involved and contribute code to this MoltenVK repository.

To contribute your code, submit a Pull Request to this repository. The first time you do this, you will be asked to agree to the MoltenVK Contributor License Agreement.

Licensing

MoltenVK is licensed under the Apache 2.0 license. All new source code files should include a copyright header at the top, containing your authorship copyright and the Apache 2.0 licensing stub. You may copy the text from an existing source code file as a template.

The Apache 2.0 license guarantees that code in the MoltenVK repository is free of Intellectual Property encumbrances. In submitting code to this repository, you are agreeing that the code is free of any Intellectual Property claims.

Vulkan Validation

Despite running on top of Metal, MoltenVK operates as a Vulkan core layer. As such, as per the error handling guidelines of the Vulkan specification, MoltenVK should not perform Vulkan validation. When adding functionality to MoltenVK, avoid adding unnecessary validation code.

Validation and error generation is appropriate within MoltenVK in cases where MoltenVK deviates from behavior defined by the Vulkan specification. This most commonly occurs when required behavior cannot be mapped to functionality available within Metal. In that situation, it is important to provide feedback to the application developer to that effect, by performing the necessary validation, and reporting an error.

Currently, there is some excess Vulkan validation and error reporting code within MoltenVK, added before this guideline was introduced. You are encouraged to remove such code if you encounter it while performing other MoltenVK development. Do not remove validation and error reporting code that is covering a deviation in behavior from the Vulkan specification.

Memory Management

Metal, and other Objective-C objects in Apple's SDK frameworks, use reference counting for memory management. As a contributor to MoltenVK, when instantiating Objective-C objects, it is important that you do not rely on the app providing autorelease pools to do memory management for you. Because many Vulkan games and apps may be ported from other platforms, they will often not automatically include autorelease pools in their threading models.

As a contributor to MoltenVK, avoid the use of the Metal autorelease method, or any object Metal creation methods that imply internal use of autorelease, (eg- [NSString stringWithFormat: ], etc). Instead, favor object creation methods that return a retained object (eg- [[NSString alloc] initWithFormat: ], etc), and manually track and release those objects. If you need to use autoreleased objects, wrap your code in an @autoreleasepool {...} block.

Code Formatting

When contributing code, please honour the code formatting style found in existing MoltenVK source code. In future, this will formally be enforced using clang-format.

moltenvk's People

Contributors

aitor-lunarg avatar antarticcoder avatar bangnoise avatar billhollings avatar cdavis5e avatar cfnptr avatar csmartdalton86 avatar danginsburg avatar epirat avatar etang-cw avatar ewouth avatar hanton avatar ifiddynine avatar js6i avatar karl-lunarg avatar kleinerm avatar lichtso avatar mbarriault avatar mbechard avatar michael-lfx avatar mmaldacker avatar mp-rsx avatar past-due avatar rcoreilly avatar ryandesign avatar spnda avatar srsaunders avatar thespydog avatar tmm1 avatar w103csh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

moltenvk's Issues

VkAttachmentDescription.stencilLoadOp and stencilStoreOp are ignored

I've been looking into why the water reflection/refraction is not rendering correctly in Dota. From the GPU Frame Debugger I see that the renderpass stencil load/store op is not correct. In this case, we have a depth load/store op that differs from the stencil load/store op. Looking in the code I see no references to VkAttachmentDescription.stencilLoadOp and VkAttachmentDescription.stencilStoreOp so that's likely the problem.

vkCmdClearAttachments of depth-stencil only when renderpass also has color causes Metal Validation error.

I am getting the following Metal Validation API error when doing vkCmdClearAttachments of a depth-stencil target in a renderpass that has one color attachment and one depth-stencil attachment.

-[MTLDebugRenderCommandEncoder validateFramebufferWithRenderPipelineState:]:1196: failed assertion `For color attachment 0, the render pipeline's pixelFormat (MTLPixelFormatInvalid) does not match the framebuffer's pixelFormat (MTLPixelFormatRGBA8Unorm_sRGB).'

I think the problem is MVKCmdClearAttachments::encode does not set the the color attachment formats because of this check:

        if (_rpsKey.isEnabled(caIdx)) {
            _rpsKey.attachmentMTLPixelFormats[caIdx] = cmdPool->mtlPixelFormatFromVkFormat(vkAttFmt);
            MTLClearColor mtlCC = mvkMTLClearColorFromVkClearValue(_vkClearValues[caIdx], vkAttFmt);
            _clearColors[caIdx] = { (float)mtlCC.red, (float)mtlCC.green, (float)mtlCC.blue, (float)mtlCC.alpha};
        }

I believe the fix is to just remove the check for _rpsKey.isEnabled because MVKCommandResourceFactory::newCmdClearMTLRenderPipelineState does this which will mask out color writes:

colorDesc.writeMask = attKey.isEnabled(caIdx) ? MTLColorWriteMaskAll : MTLColorWriteMaskNone;

Deadlocks on vkDeviceWaitIdle and vkQueueWaitIdle

The problem

The program randomly gets completely stuck on VkDeviceWaitIdle/VkQueueWaitIdle. It always happens when I'm resizing my window, but also when not calling vkDeviceWaitIdle in my render loop and trying to quit the program. The program waits inside vkDeviceWaitIdle()/vkQueueWaitIdle() and the mvkDispatcher thread is waiting on a condition_variable.

It seems to me that vkDeviceWaitIdle() and vkQueueWaitIdle() should never block forever, no matter what.

The MvkDispatcher thread gets stuck on semaphore_timedwait_trap, while the main thread is blocked on MVKSemaphore::wait()

How to reproduce

Copy the code from vulkan-tutorial and remove the vkDeviceWaitIdle call in the render loop. Now start to resize the window. The program will halt.

My configuration

Mac Pro 3.1 macOS 10.13.3 using the LunarG macOS SDK 1.0.69, linked against vulkan-1 loader library.

Should [mvk-info] messages be turned off?

Related to #41, I think...

When I run vulkaninfo in Terminal, I see:

[mvk-info] Created VkDevice to run on GPU AMD Radeon Pro 560

and various other [mvk-info] messages.

These messages also show up in a Xcode panel when running windowed apps.

This happens even with the Release build. Is this expected or do we want these messages off by default and able to be turned back on via some setting or compile option?

Lots of files in the source have executable permission

I was trying to find the compiled example binaries by searching for executables and was surprised to see lots of the files in the source are executable (see below for a full list).

From a fresh clone you can run find . -type f -perm +0111 | grep -v .git to get a list of executable files in the tree. README.md is one of them:

$ ls -lah README.md
-rwxr-xr-x  1 andy  andy  14K  9 Mar 13:12 README.md

GitHub shows the same:

screen shot 2018-03-09 at 13 15 19

Is there a reason for it? If not, do you want a small PR to drop the executable permission for non-executable files? Otherwise, feel free to close this issue.

Click to expand full list of executable files in source tree
$ find . -type f -perm +0111 | grep -v .git
./Docs/images/MoltenVK-Logo-Banner.png
./Docs/MoltenVK_Runtime_UserGuide.md
./README.md
./Common/MVKLogging.h
./External/getLatestSPIRVTools
./External/getLatestVulkanSpec
./External/SPIRV-Cross/test_shaders.sh
./External/SPIRV-Cross/format_all.sh
./External/SPIRV-Cross/checkout_glslang_spirv_tools.sh
./External/SPIRV-Cross/update_test_shaders.sh
./External/SPIRV-Cross/.clang-format
./External/SPIRV-Cross/shaders/vert/ground.vert
./External/SPIRV-Cross/shaders/frag/ground.frag
./External/SPIRV-Cross/test_shaders.py
./External/SPIRV-Tools/utils/check_copyright.py
./External/SPIRV-Tools/utils/generate_registry_tables.py
./External/SPIRV-Tools/utils/check_code_format.sh
./External/SPIRV-Tools/utils/generate_grammar_tables.py
./External/SPIRV-Tools/utils/generate_language_headers.py
./External/SPIRV-Tools/utils/update_build_version.py
./External/SPIRV-Tools/utils/generate_vim_syntax.py
./External/SPIRV-Tools/utils/check_symbol_exports.py
./External/getLatestVulkanSamples
./External/makeglslang
./External/Vulkan-LoaderAndValidationLayers/layers/vu_csv_stats.sh
./External/Vulkan-LoaderAndValidationLayers/tests/vkvalidatelayerdoc.sh
./External/Vulkan-LoaderAndValidationLayers/tests/run_all_tests.sh
./External/Vulkan-LoaderAndValidationLayers/tests/run_wrap_objects_tests.sh
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/xcode/Scripts/versiongenerate.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/build-aux/install-sh
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/build-aux/config.guess
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/build-aux/depcomp
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/build-aux/missing
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/build-aux/config.sub
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest_prod_test-md.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest_main.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest.sln
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest_unittest-md.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest_unittest.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest_prod_test.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest-md.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest-md.sln
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/msvc/gtest_main-md.vcproj
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_xml_output_unittest.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_uninitialized_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_color_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_break_on_failure_unittest.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_help_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_shuffle_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_filter_unittest.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_test_utils.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_catch_exceptions_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_xml_outfiles_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_output_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_xml_test_utils.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_throw_on_failure_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_list_tests_unittest.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/test/gtest_env_var_test.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/configure
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/scripts/pump.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/scripts/fuse_gtest_files.py
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/scripts/gtest-config.in
./External/Vulkan-LoaderAndValidationLayers/tests/gtest-1.7.0/scripts/gen_gtest_pred_impl.py
./External/Vulkan-LoaderAndValidationLayers/tests/run_extra_loader_tests.sh
./External/Vulkan-LoaderAndValidationLayers/tests/run_loader_tests.sh
./External/Vulkan-LoaderAndValidationLayers/windowsRuntimeInstaller/CreateInstallerRT.sh
./External/Vulkan-LoaderAndValidationLayers/update_external_sources.sh
./External/Vulkan-LoaderAndValidationLayers/loader/loader.rc
./External/Vulkan-LoaderAndValidationLayers/scripts/check_code_format.sh
./External/Vulkan-LoaderAndValidationLayers/scripts/determine_vs_version.py
./External/Vulkan-LoaderAndValidationLayers/scripts/generator.py
./External/Vulkan-LoaderAndValidationLayers/scripts/reg.py
./External/Vulkan-LoaderAndValidationLayers/scripts/vk_validation_stats.py
./External/Vulkan-LoaderAndValidationLayers/scripts/check_toolchain_revisions.sh
./External/Vulkan-LoaderAndValidationLayers/demos/smoke/android/gradlew
./External/Vulkan-LoaderAndValidationLayers/demos/smoke/android/build-and-install
./External/Vulkan-LoaderAndValidationLayers/demos/smoke/glsl-to-spirv
./External/Vulkan-LoaderAndValidationLayers/demos/smoke/generate-dispatch-table.py
./External/Vulkan-LoaderAndValidationLayers/demos/cube.vcxproj.user
./External/Vulkan-LoaderAndValidationLayers/demos/vulkaninfo.vcxproj.user
./External/Vulkan-LoaderAndValidationLayers/build-android/build_all.sh
./External/Vulkan-LoaderAndValidationLayers/build-android/android-generate.sh
./External/Vulkan-LoaderAndValidationLayers/build-android/update_external_sources_android.sh
./External/Vulkan-LoaderAndValidationLayers/build-android/test_APK.sh
./External/Vulkan-LoaderAndValidationLayers/build-android/install_all.sh
./External/Vulkan-LoaderAndValidationLayers/build-android/update_external_sources_android.bat
./External/getLatestSPIRVCross
./External/glslang/Test/hlsl.namespace.frag
./External/glslang/Test/spv.functionNestedOpaque.vert
./External/glslang/Test/hlsl.flattenSubset.frag
./External/glslang/Test/hlsl.flattenSubset2.frag
./External/glslang/Test/spv.targetVulkan.vert
./External/glslang/Test/hlsl.this.frag
./External/glslang/Test/badMacroArgs.frag
./External/glslang/Test/nosuffix
./External/glslang/Test/runtests
./External/glslang/Test/hlsl.partialInit.frag
./External/glslang/Test/hlsl.charLit.vert
./External/glslang/Test/hlsl.hlslOffset.vert
./External/glslang/Test/hlsl.amend.frag
./External/glslang/Test/spv.offsets.frag
./External/glslang/Test/hlsl.nonstaticMemberFunction.frag
./External/glslang/Test/hlsl.logicalConvert.frag
./External/glslang/Test/hlsl.structStructName.frag
./External/glslang/Test/spv.hlslOffsets.vert
./External/glslang/Test/hlsl.staticMemberFunction.frag
./External/glslang/Test/hlsl.structIoFourWay.frag
./External/glslang/Test/spv.targetOpenGL.vert
./External/glslang/Test/cppBad2.vert
./External/glslang/Test/hlsl.shapeConvRet.frag
./External/glslang/Test/hlsl.inf.vert
./External/glslang/Test/hlsl.multiReturn.frag
./External/glslang/Test/hlsl.string.frag
./External/glslang/Test/hlsl.boolConv.vert
./External/glslang/Test/hlsl.implicitBool.frag
./External/glslang/Test/hlsl.multiEntry.vert
./External/glslang/Test/validate-shaders.sh
./External/glslang/Test/baseLegalResults/hlsl.flattenSubset2.frag.out
./External/glslang/Test/baseLegalResults/hlsl.partialFlattenLocal.vert.out
./External/glslang/Test/baseLegalResults/hlsl.partialFlattenMixed.vert.out
./External/glslang/Test/baseLegalResults/hlsl.flattenSubset.frag.out
./External/glslang/Test/bump
./External/glslang/Test/spv.multiStructFuncall.frag
./External/glslang/Test/baseResults/spv.400.tese.out
./External/glslang/Test/baseResults/spv.storageBuffer.vert.out
./External/glslang/Test/baseResults/spv.forwardFun.frag.out
./External/glslang/Test/baseResults/spv.conversion.frag.out
./External/glslang/Test/baseResults/spv.460.vert.out
./External/glslang/Test/baseResults/hlsl.doLoop.frag.out
./External/glslang/Test/baseResults/hlsl.max.frag.out
./External/glslang/Test/baseResults/hlsl.partialInit.frag.out
./External/glslang/Test/baseResults/cppBad.vert.out
./External/glslang/Test/baseResults/hlsl.buffer.frag.out
./External/glslang/Test/baseResults/implicitInnerAtomicUint.frag.out
./External/glslang/Test/baseResults/hlsl.flattenSubset2.frag.out
./External/glslang/Test/baseResults/spv.310.bitcast.frag.out
./External/glslang/Test/baseResults/spv.glFragColor.frag.out
./External/glslang/Test/baseResults/glspv.frag.out
./External/glslang/Test/baseResults/hlsl.semantic.geom.out
./External/glslang/Test/baseResults/spv.450.noRedecl.tesc.out
./External/glslang/Test/baseResults/hlsl.init.frag.out
./External/glslang/Test/baseResults/spv.set.vert.out
./External/glslang/Test/baseResults/cppPassMacroName.frag.out
./External/glslang/Test/baseResults/hlsl.constructArray.vert.out
./External/glslang/Test/baseResults/hlsl.targetStruct1.frag.out
./External/glslang/Test/baseResults/spv.430.frag.out
./External/glslang/Test/baseResults/hlsl.attributeGlobalBuffer.frag.out
./External/glslang/Test/baseResults/320.geom.out
./External/glslang/Test/baseResults/hlsl.hull.3.tesc.out
./External/glslang/Test/baseResults/spv.accessChain.frag.out
./External/glslang/Test/baseResults/hlsl.conditional.frag.out
./External/glslang/Test/baseResults/hlsl.structIoFourWay.frag.out
./External/glslang/Test/baseResults/hlsl.shapeConvRet.frag.out
./External/glslang/Test/baseResults/spv.texture.frag.out
./External/glslang/Test/baseResults/spv.functionSemantics.frag.out
./External/glslang/Test/baseResults/hlsl.precedence2.frag.out
./External/glslang/Test/baseResults/spv.Operations.frag.out
./External/glslang/Test/baseResults/hlsl.matrixSwizzle.vert.out
./External/glslang/Test/baseResults/spv.earlyReturnDiscard.frag.out
./External/glslang/Test/baseResults/spv.discard-dce.frag.out
./External/glslang/Test/baseResults/hlsl.layout.frag.out
./External/glslang/Test/baseResults/hlsl.matType.frag.out
./External/glslang/Test/baseResults/spv.dataOutIndirect.vert.out
./External/glslang/Test/baseResults/spv.barrier.vert.out
./External/glslang/Test/baseResults/spv.multiView.frag.out
./External/glslang/Test/baseResults/hlsl.boolConv.vert.out
./External/glslang/Test/baseResults/spv.swizzle.frag.out
./External/glslang/Test/baseResults/spv.460.comp.out
./External/glslang/Test/baseResults/glspv.version.frag.out
./External/glslang/Test/baseResults/hlsl.depthLess.frag.out
./External/glslang/Test/baseResults/410.vert.out
./External/glslang/Test/baseResults/spv.300layoutp.vert.out
./External/glslang/Test/baseResults/spv.voidFunction.frag.out
./External/glslang/Test/baseResults/hlsl.void.frag.out
./External/glslang/Test/baseResults/hlsl.overload.frag.out
./External/glslang/Test/baseResults/hlsl.logicalConvert.frag.out
./External/glslang/Test/baseResults/spv.140.frag.out
./External/glslang/Test/baseResults/hlsl.typeGraphCopy.vert.out
./External/glslang/Test/baseResults/hlsl.amend.frag.out
./External/glslang/Test/baseResults/spv.forLoop.frag.out
./External/glslang/Test/baseResults/spv.loops.frag.out
./External/glslang/Test/baseResults/hlsl.pp.vert.out
./External/glslang/Test/baseResults/spv.swizzleInversion.frag.out
./External/glslang/Test/baseResults/hlsl.scalarCast.vert.out
./External/glslang/Test/baseResults/hlsl.basic.comp.out
./External/glslang/Test/baseResults/spv.double.comp.out
./External/glslang/Test/baseResults/spv.structure.frag.out
./External/glslang/Test/baseResults/460.vert.out
./External/glslang/Test/baseResults/spv.multiStructFuncall.frag.out
./External/glslang/Test/baseResults/spv.paramMemory.frag.out
./External/glslang/Test/baseResults/spv.450.geom.out
./External/glslang/Test/baseResults/hlsl.discard.frag.out
./External/glslang/Test/baseResults/spv.do-simple.vert.out
./External/glslang/Test/baseResults/spv.functionCall.frag.out
./External/glslang/Test/baseResults/hlsl.flattenOpaque.frag.out
./External/glslang/Test/baseResults/hlsl.sin.frag.out
./External/glslang/Test/baseResults/hlsl.float1.frag.out
./External/glslang/Test/baseResults/435.vert.out
./External/glslang/Test/baseResults/hlsl.this.frag.out
./External/glslang/Test/baseResults/spv.precision.frag.out
./External/glslang/Test/baseResults/spv.150.geom.out
./External/glslang/Test/baseResults/hlsl.flattenOpaqueInit.vert.out
./External/glslang/Test/baseResults/hlsl.namespace.frag.out
./External/glslang/Test/baseResults/hlsl.if.frag.out
./External/glslang/Test/baseResults/hlsl.target.frag.out
./External/glslang/Test/baseResults/spv.uint.frag.out
./External/glslang/Test/baseResults/spv.queryL.frag.out
./External/glslang/Test/baseResults/spv.newTexture.frag.out
./External/glslang/Test/baseResults/320.frag.out
./External/glslang/Test/baseResults/spv.offsets.frag.out
./External/glslang/Test/baseResults/400.vert.out
./External/glslang/Test/baseResults/spv.conditionalDiscard.frag.out
./External/glslang/Test/baseResults/hlsl.structStructName.frag.out
./External/glslang/Test/baseResults/hlsl.PointSize.vert.out
./External/glslang/Test/baseResults/hlsl.precedence.frag.out
./External/glslang/Test/baseResults/spv.varyingArray.frag.out
./External/glslang/Test/baseResults/spv.flowControl.frag.out
./External/glslang/Test/baseResults/320.tesc.out
./External/glslang/Test/baseResults/hlsl.include.vert.out
./External/glslang/Test/baseResults/spv.atomic.comp.out
./External/glslang/Test/baseResults/hlsl.staticMemberFunction.frag.out
./External/glslang/Test/baseResults/spv.xfb.vert.out
./External/glslang/Test/baseResults/hlsl.typedef.frag.out
./External/glslang/Test/baseResults/320.vert.out
./External/glslang/Test/baseResults/hlsl.scope.frag.out
./External/glslang/Test/baseResults/hlsl.attribute.frag.out
./External/glslang/Test/baseResults/spv.length.frag.out
./External/glslang/Test/baseResults/hlsl.function.frag.out
./External/glslang/Test/baseResults/spv.depthOut.frag.out
./External/glslang/Test/baseResults/spv.localAggregates.frag.out
./External/glslang/Test/baseResults/hlsl.semantic.vert.out
./External/glslang/Test/baseResults/hlsl.partialFlattenLocal.vert.out
./External/glslang/Test/baseResults/spv.ssboAlias.frag.out
./External/glslang/Test/baseResults/spv.sample.frag.out
./External/glslang/Test/baseResults/hlsl.forLoop.frag.out
./External/glslang/Test/baseResults/320.tese.out
./External/glslang/Test/baseResults/spv.doWhileLoop.frag.out
./External/glslang/Test/baseResults/hlsl.string.frag.out
./External/glslang/Test/baseResults/spv.qualifiers.vert.out
./External/glslang/Test/baseResults/spv.for-simple.vert.out
./External/glslang/Test/baseResults/spv.simpleMat.vert.out
./External/glslang/Test/baseResults/hlsl.nonstaticMemberFunction.frag.out
./External/glslang/Test/baseResults/spv.specConst.vert.out
./External/glslang/Test/baseResults/vulkan.ast.vert.out
./External/glslang/Test/baseResults/460.frag.out
./External/glslang/Test/baseResults/spv.variableArrayIndex.frag.out
./External/glslang/Test/baseResults/hlsl.targetStruct2.frag.out
./External/glslang/Test/baseResults/hlsl.includeNegative.vert.out
./External/glslang/Test/baseResults/hlsl.aliasOpaque.frag.out
./External/glslang/Test/baseResults/hlsl.cast.frag.out
./External/glslang/Test/baseResults/hlsl.struct.frag.out
./External/glslang/Test/baseResults/hlsl.float4.frag.out
./External/glslang/Test/baseResults/tokenPaste.vert.out
./External/glslang/Test/baseResults/spv.structAssignment.frag.out
./External/glslang/Test/baseResults/spv.pushConstantAnon.vert.out
./External/glslang/Test/baseResults/hlsl.layoutOverride.vert.out
./External/glslang/Test/baseResults/hlsl.memberFunCall.frag.out
./External/glslang/Test/baseResults/320.comp.out
./External/glslang/Test/baseResults/spv.dataOut.frag.out
./External/glslang/Test/baseResults/hlsl.entry-out.frag.out
./External/glslang/Test/baseResults/missingBodies.vert.out
./External/glslang/Test/baseResults/cppDeepNest.frag.out
./External/glslang/Test/baseResults/spv.while-simple.vert.out
./External/glslang/Test/baseResults/hlsl.partialFlattenMixed.vert.out
./External/glslang/Test/baseResults/hlsl.shapeConv.frag.out
./External/glslang/Test/baseResults/spv.drawParams.vert.out
./External/glslang/Test/baseResults/spv.builtInXFB.vert.out
./External/glslang/Test/baseResults/glspv.esversion.vert.out
./External/glslang/Test/baseResults/glspv.version.vert.out
./External/glslang/Test/baseResults/spv.450.tesc.out
./External/glslang/Test/baseResults/hlsl.synthesizeInput.frag.out
./External/glslang/Test/baseResults/hlsl.structin.vert.out
./External/glslang/Test/baseResults/420.comp.out
./External/glslang/Test/baseResults/spv.nonSquare.vert.out
./External/glslang/Test/baseResults/hlsl.flattenSubset.frag.out
./External/glslang/Test/baseResults/hlsl.inf.vert.out
./External/glslang/Test/baseResults/spv.dataOutIndirect.frag.out
./External/glslang/Test/baseResults/spv.300layout.frag.out
./External/glslang/Test/baseResults/hlsl.switch.frag.out
./External/glslang/Test/baseResults/hlsl.array.frag.out
./External/glslang/Test/baseResults/spv.simpleFunctionCall.frag.out
./External/glslang/Test/baseResults/spv.noWorkgroup.comp.out
./External/glslang/Test/baseResults/spv.textureBuffer.vert.out
./External/glslang/Test/baseResults/hlsl.swizzle.frag.out
./External/glslang/Test/baseResults/spv.100ops.frag.out
./External/glslang/Test/baseResults/hlsl.depthGreater.frag.out
./External/glslang/Test/baseResults/hlsl.whileLoop.frag.out
./External/glslang/Test/baseResults/hlsl.entry-in.frag.out
./External/glslang/Test/baseResults/spv.texture.vert.out
./External/glslang/Test/baseResults/spv.sampleId.frag.out
./External/glslang/Test/baseResults/hlsl.charLit.vert.out
./External/glslang/Test/baseResults/hlsl.implicitBool.frag.out
./External/glslang/Test/baseResults/spv.300BuiltIns.vert.out
./External/glslang/Test/baseResults/spv.whileLoop.frag.out
./External/glslang/Test/baseResults/spv.prepost.frag.out
./External/glslang/Test/baseResults/spv.430.vert.out
./External/glslang/Test/baseResults/spv.types.frag.out
./External/glslang/Test/baseResults/hlsl.flattenOpaqueInitMix.vert.out
./External/glslang/Test/baseResults/hlsl.multiReturn.frag.out
./External/glslang/Test/baseResults/hlsl.attributeC11.frag.out
./External/glslang/Test/baseResults/hlsl.PointSize.geom.out
./External/glslang/Test/baseResults/hlsl.multiEntry.vert.out
./External/glslang/Test/baseResults/spv.deviceGroup.frag.out
./External/glslang/Test/baseResults/spv.loopsArtificial.frag.out
./External/glslang/Test/baseResults/spv.multiStruct.comp.out
./External/glslang/Test/baseResults/spv.switch.frag.out
./External/glslang/Test/baseResults/glspv.vert.out
./External/glslang/Test/baseResults/spv.matFun.vert.out
./External/glslang/Test/baseResults/cppBad2.vert.out
./External/glslang/Test/baseResults/spv.460.frag.out
./External/glslang/Test/baseResults/spv.structDeref.frag.out
./External/glslang/Test/baseResults/spv.150.vert.out
./External/glslang/Test/baseResults/spv.varyingArrayIndirect.frag.out
./External/glslang/Test/baseResults/hlsl.assoc.frag.out
./External/glslang/Test/baseResults/spv.always-discard2.frag.out
./External/glslang/Test/baseResults/spv.precisionNonESSamp.frag.out
./External/glslang/Test/baseResults/spv.samplePosition.frag.out
./External/glslang/Test/glslangValidator
./External/glslang/Test/hlsl.scalarCast.vert
./External/glslang/Test/420.comp
./External/glslang/Test/spv.shortCircuit.frag
./External/glslang/update_glslang_sources.py
./External/glslang/SPIRV/SPVRemapper.h
./External/glslang/SPIRV/SpvBuilder.h
./External/glslang/SPIRV/CMakeLists.txt
./External/glslang/SPIRV/spirv.hpp
./External/glslang/SPIRV/GlslangToSpv.cpp
./External/glslang/SPIRV/spvIR.h
./External/glslang/SPIRV/disassemble.h
./External/glslang/SPIRV/GLSL.std.450.h
./External/glslang/SPIRV/SPVRemapper.cpp
./External/glslang/SPIRV/doc.cpp
./External/glslang/glslang/updateGrammar
./External/glslang/glslang/MachineIndependent/parseVersions.h
./External/glslang/make-revision
./External/glslang/hlsl/hlslParseables.cpp
./External/glslang/hlsl/hlslTokenStream.cpp
./External/glslang/hlsl/CMakeLists.txt
./External/glslang/hlsl/hlslParseables.h
./External/glslang/hlsl/hlslParseHelper.cpp
./External/glslang/hlsl/hlslScanContext.cpp
./External/glslang/hlsl/hlslParseHelper.h
./External/glslang/hlsl/hlslOpMap.cpp
./External/glslang/hlsl/hlslScanContext.h
./External/glslang/hlsl/hlslTokens.h
./External/glslang/hlsl/hlslOpMap.h
./External/glslang/hlsl/hlslGrammar.cpp
./External/glslang/hlsl/hlslTokenStream.h
./External/glslang/hlsl/hlslGrammar.h
./External/VulkanSamples/Sample-Programs/Hologram/android/gradlew
./External/VulkanSamples/Sample-Programs/Hologram/android/build-and-install
./External/VulkanSamples/Sample-Programs/Hologram/glsl-to-spirv
./External/VulkanSamples/Sample-Programs/Hologram/generate-dispatch-table
./External/VulkanSamples/API-Samples/Tutorial/tools/Markdown.pl
./External/VulkanSamples/API-Samples/Tutorial/build.sh
./External/VulkanSamples/API-Samples/get-short-descripts.sh
./External/VulkanSamples/API-Samples/get-descripts.sh
./External/VulkanSamples/API-Samples/run_all_samples.sh
./External/VulkanSamples/API-Samples/android/gradlew
./External/VulkanSamples/tests/vkvalidatelayerdoc.sh
./External/VulkanSamples/tests/run_all_tests.sh
./External/VulkanSamples/tests/run_wrap_objects_tests.sh
./External/VulkanSamples/tests/gtest-1.7.0/xcode/Scripts/versiongenerate.py
./External/VulkanSamples/tests/gtest-1.7.0/build-aux/install-sh
./External/VulkanSamples/tests/gtest-1.7.0/build-aux/config.guess
./External/VulkanSamples/tests/gtest-1.7.0/build-aux/depcomp
./External/VulkanSamples/tests/gtest-1.7.0/build-aux/missing
./External/VulkanSamples/tests/gtest-1.7.0/build-aux/config.sub
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest_prod_test-md.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest_main.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest.sln
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest_unittest-md.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest_unittest.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest_prod_test.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest-md.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest-md.sln
./External/VulkanSamples/tests/gtest-1.7.0/msvc/gtest_main-md.vcproj
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_xml_output_unittest.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_uninitialized_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_color_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_break_on_failure_unittest.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_help_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_shuffle_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_filter_unittest.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_test_utils.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_catch_exceptions_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_xml_outfiles_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_output_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_xml_test_utils.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_throw_on_failure_test.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_list_tests_unittest.py
./External/VulkanSamples/tests/gtest-1.7.0/test/gtest_env_var_test.py
./External/VulkanSamples/tests/gtest-1.7.0/configure
./External/VulkanSamples/tests/gtest-1.7.0/scripts/pump.py
./External/VulkanSamples/tests/gtest-1.7.0/scripts/fuse_gtest_files.py
./External/VulkanSamples/tests/gtest-1.7.0/scripts/gtest-config.in
./External/VulkanSamples/tests/gtest-1.7.0/scripts/gen_gtest_pred_impl.py
./External/VulkanSamples/tests/run_extra_loader_tests.sh
./External/VulkanSamples/tests/run_loader_tests.sh
./External/VulkanSamples/windowsRuntimeInstaller/CreateInstallerRT.sh
./External/VulkanSamples/update_external_sources.sh
./External/VulkanSamples/Utilities/WSIWindow_Sample1/android/gradlew
./External/VulkanSamples/Utilities/WSIWindow_Sample1/android/clean.sh
./External/VulkanSamples/Utilities/WSIWindow/clang.sh
./External/VulkanSamples/samples_images/memory_barriers.png
./External/VulkanSamples/loader/loader.rc
./External/VulkanSamples/scripts/determine_vs_version.py
./External/VulkanSamples/scripts/generator.py
./External/VulkanSamples/scripts/reg.py
./External/VulkanSamples/scripts/vk_validation_stats.py
./External/VulkanSamples/scripts/source_line_info.py
./External/VulkanSamples/demos/smoke/android/gradlew
./External/VulkanSamples/demos/smoke/android/build-and-install
./External/VulkanSamples/demos/smoke/glsl-to-spirv
./External/VulkanSamples/demos/smoke/generate-dispatch-table.py
./External/VulkanSamples/demos/cube.vcxproj.user
./External/VulkanSamples/demos/vulkaninfo.vcxproj.user
./External/VulkanSamples/build-android/build_all.sh
./External/VulkanSamples/build-android/android-generate.sh
./External/VulkanSamples/build-android/update_external_sources_android.sh
./External/VulkanSamples/build-android/test_APK.sh
./External/VulkanSamples/build-android/install_all.sh
./External/VulkanSamples/build-android/update_external_sources_android.bat
./External/makeSPIRVTools
./External/makeAll
./External/makeVulkanSpec
./External/SPIRV-Headers/include/spirv/1.2/spirv.py
./External/Vulkan-Hpp/tinyxml2/tinyxml2.cpp
./External/Vulkan-Hpp/tinyxml2/resources/dream.xml
./External/Vulkan-Hpp/tinyxml2/resources/utf8test.xml
./External/Vulkan-Hpp/tinyxml2/resources/utf8testverify.xml
./External/Vulkan-Hpp/tinyxml2/tinyxml2.h
./External/Vulkan-Hpp/tinyxml2/tinyxml2/tinyxml2.sln
./External/Vulkan-Hpp/tinyxml2/tinyxml2/tinyxml2.vcxproj
./External/Vulkan-Hpp/tinyxml2/tinyxml2/tinyxml2.vcxproj.filters
./External/Vulkan-Hpp/tinyxml2/setversion.py
./External/Vulkan-Hpp/Vulkan-Docs/update_valid_usage_ids.sh
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/sandboxCopy
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/makeAllExts
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/config/optimize-pdf
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/config/makeSubmit.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/genRef.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/makeKHR
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/appendices/VK_AMD_negative_viewport_height.txt
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/makeExt
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/reflow.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/makeKHRAndKHX
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/scripts/insertTags.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/scripts/htmldiff.pl
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/scripts/htmldiff
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/scripts/checkXrefs
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/scripts/htmldiff.orig
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/scripts/findBalance.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/fixupRef.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/checkLinks.py
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/genRelease
./External/Vulkan-Hpp/Vulkan-Docs/doc/specs/vulkan/installRelease
./External/Vulkan-Hpp/Vulkan-Docs/src/spec/genvk.py
./External/Vulkan-Hpp/Vulkan-Docs/src/spec/reg.py
./External/Vulkan-Hpp/Vulkan-Docs/src/spec/indexExt.py
./External/Vulkan-Hpp/Vulkan-Docs/src/spec/realign.py
./External/Vulkan-Hpp/Vulkan-Docs/src/spec/extDependency.py
./External/getLatestAll
./External/getLatestVulkanLVL
./External/getLatestglslang
./Demos/LunarG-VulkanSamples/API-Samples/iOS/Resources/Icon.png
./Demos/LunarG-VulkanSamples/API-Samples/iOS/Resources/[email protected]
./Demos/LunarG-VulkanSamples/API-Samples/iOS/Resources/Default~ipad.png
./Demos/LunarG-VulkanSamples/Hologram/iOS/Resources/Icon.png
./Demos/LunarG-VulkanSamples/Hologram/iOS/Resources/[email protected]
./Demos/LunarG-VulkanSamples/Hologram/iOS/Resources/Default~ipad.png
./Demos/LunarG-VulkanSamples/Demos/iOS/Resources/Icon.png
./Demos/LunarG-VulkanSamples/Demos/iOS/Resources/[email protected]
./Demos/LunarG-VulkanSamples/Demos/iOS/Resources/Default~ipad.png
./Demos/README.md

vkCmdCopyBufferToImage with the BC3_SRGB_BLOCK format when imageExtent + imageOffset equals the subresource dimensions, but is less than the compressed texel block dimensions, causes Metal assertion failure

According to section 18.4 of the Vulkan spec, one of the valid uses of the VkBufferImageCopy struct is that (imageExtent[.width/height/depth] + imageOffset[.x/y/z]) must equal the image subresource width/height/depth respectively, when the VkImage of vkCmdCopyBufferToImage has a compressed format.

This causes a validation failure in the copyFromBuffer method of the MTLBlitCommandEncoder when (imageExtent + imageOffset) is less than the block size, but equal to the subresource dimensions, because the mvkMTLPixelFormatBytesPerRow function performs an integer division with the block size, and thus calculates sourceBytesPerRow erroneously as 0. The same is true for the mvkMTLPixelFormatBytesPerLayer function, which wrongly calculates the sourceBytesPerImage (as 0).

The format of the image used in the offending call was VK_FORMAT_BC3_SRGB_BLOCK, but I'd expect any BC3 format to behave this way.

vkCmdClearDepthStencilImage causes Metal validation error: PixelFormat xyz is not color renderable

I'm attempting to run my graphics library on top of MoltenVK. In it, I clear depth stencil images after they are created so that they can be presented immediately. Essentially, all I am doing is creating a VkImage with format VK_FORMAT_D16_UNORM and depth-stencil, transfer src, and transfer dst usage bits. Then, I create a command buffer and issue a call to vkCmdClearDepthStencilImage where the depth and stencil values are 0.

This generates a Metal validation error. Running under Xcode with "extended" Metal validation gives this information:

validateAttachmentOnDevice:248: failed assertion `PixelFormat MTLPixelFormatDepth16Unorm is not color renderable'

I'm definitely not familiar with the code here at all, but it looks like the procedure for doing this might be trying to use the given texture as a color attachment.

Consider making logging controllable at run time

Currently, MVK logging level is set as a compile-time option. It may be useful to change this to a run-time option, controlled by an environment variable. The Linux system loader does this via the LD_DEBUG environment variable and the Vulkan loader does it via VK_LOADER_DEBUG.

This would obviate the need to "keep around" or build MVK libs with various logging options. It would also facilitate debugging in the field by asking the user to run their failing scenario with the env var turned on and then collect and forward the output for analysis.

Feature request: VK_EXT_debug_marker for GPU frame capture

It would be very useful if MoltenVK could support VK_EXT_debug_marker and pass the markers down to Metal so that they showed up during GPU Frame Capture. For example, in Source 2 we label all command buffers and many resources and seeing that within the Metal GPU Frame Capture would be very helpful.

MoltenVK reports it does not support VK_FORMAT_BC1_RGB_UNORM, I suspect it can

MoltenVK reports in vkGetPhysicalDeviceFormatProperties that it can't support VK_FORMAT_BC1_RGB_UNORM. I believe the reason for this is because Metal claims to only support BC1_RGBA.

However, my understanding is that the difference between BC1_RGB and BC1_RGBA is just whether color0 <= color1 in the 16-bit texture values. In other words, I suspect MoltenVK might work just fine with BC1_RGB since the texture will be encoded with color0 > color1 and thus alpha will always be one (the transparent color is never used).

I've worked around this for now in Source 2.

Metal backend layer for Qt Window

Hello,

Maybe my question will be out of scope, but i'm trying to integrate MoltenVK to my vulkan application which is currently using Qt to manage windows. The issue comes from the surface creation :

[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: On-screen rendering requires a view that is backed by a layer of type CAMetalLayer.

As far as I understand, my window - which inherits directly from QWindow, and is recognized by the surface create info structure using the QWindow::WId member - seems to not have the requirements to get Metal working on it.

I was looking for some answers about the same issue on the web, but surprisingly i didn't find anything interesting. So i try here.

Did anyone have a chance to get MoltenVK and Qt working in the same application on OSX ?

Thank you.

cmake is a dependency

(Homebrew's) cmake is required to build third party dependencies. It should be added "Installing MoltenVK" README.md section.

Using vkCmdClearAttachments with no stencil attachment sometimes causes Metal validation error

I'm seeing that calling vkCmdClearAttachments under MoltenVK sometimes causes this sort of validation error:

validateDepthStencilState:3671: failed assertion `MTLDepthStencilDescriptor uses frontFaceStencil but MTLRenderPassDescriptor has a nil stencilAttachment texture'

From the stack trace, it looks like this validation error is being hit in a synthetic draw command being issued inside of MVKCmdClearAttachments::encode. The error does not get triggered until the command buffer is actually submitted/executed.

Note that my application doesn't have or attempt to use a stencil texture or attachment.

MVKBufferView::getMTLTexture(): MTLTextureDescriptor has width (786432) greater than the maximum allowed size of 16384

'Large' textures aren't loaded as throws an exception for height/widths above 16384.

MTLTextureDescriptor* mtlTexDesc = [MTLTextureDescriptor texture2DDescriptorWithPixelFormat: _mtlPixelFormat
width: _textureSize.width
height: _textureSize.height
mipmapped: NO];
_mtlTexture = [getMTLBuffer() newTextureWithDescriptor: mtlTexDesc
offset: _mtlBufferOffset
bytesPerRow: mtlByteCnt];

My texture is a 512x512 pixel texture (RGB8), so a width of 786432 makes sense (512*512*3) if you have a height of 1. Is the intended behavior? (see below):

// Layout texture as a 1D array of texel blocks (which are texels for non-compressed textures) that covers the bytes
_byteCount = pCreateInfo->range;
if (_byteCount == VK_WHOLE_SIZE) { _byteCount = _buffer->getByteCount() - _mtlBufferOffset; } // Remaining bytes in buffer
size_t blockCount = _byteCount / bytesPerBlock;
_byteCount = blockCount * bytesPerBlock; // Round down
_textureSize.width = (uint32_t)blockCount * fmtBlockSize.width;
_textureSize.height = fmtBlockSize.height;

How can I load textures where height*width is greater than 16384?

Sorry if it's obvious, I'm new to Vulkan, able to try it out because of MoltenVK being open-source (which is awesome!).

Please consider using glslang "known_good"

The glslang and SPIRV folks have done some things to make sure that the revisions of SPIRV-Tools and SPIRV-Headers are compatible with a given revision of glslang. There is a update_glslang_sources.py script and a known_good.json file in the top of the glslang repo that are used to fetch the compatible versions of SPIRV-Tools and SPIRV-Headers for glslang. These fetches are done in "external" directories inside the glslang tree (and not as siblings to glslang).

This approach ensures that the correct versions of the three repos are used. Currently, this repo just pulls the latest of each of the three independently, which someday may cause a problem.

This concern should probably be motivation enough for switching, but there are other advantages.

The KhronosGroup/Vulkan-LoaderAndValidationLayers (LVL) repo pulls in (pending a PR) this MoltenVK repo as part of its build process. The LVL repo also pulls in its own copy of glslang at a very specific "approved" revision. It also uses the "known_good" approach to ensure that it gets the correct SPIRV revisions for the "approved" glslang revision.

Basically, the LVL build ends up fetching and building glslang/SPIRV twice since MoltenVK is doing it too. Worse, this arrangement can fetch and build different versions of these repos.

What I would like to be able to do is:

  • Continue letting LVL build the glslang using the known_good approach. (It builds SPIRV as well this way)
  • When building LVL for macOS, clone and build MoltenVK, but don't let MoltenVK fetch or build glslang and SPIRV
    • Don't clone the glslang and SPIRV submodules
    • Don't call the glslang/SPIRV build scripts in MoltenVK/External
  • Put a symlink from MoltenVK/External/glslang to the the glslang that LVL built

I can't do something like replacing the three existing submodules in MoltenVK/External with symlinks to my LVL build of glslang because the build folders that contain things that MoltenVK needs end up being in different places. Some of the paths to SPIRV build artifacts (e.g., extension_enum.inc) have to change in the MoltenVK Converter project (at least). This is because the build folders in the three-repo arrangement (MVK) are in different places than in the one-repo arrangement (LVL).

I would like MoltenVK to build glslang/SPIRV using the "known_good" single-repo approach so that I can just tell it to use my glslang tree instead of using its own.

So, the steps needed for MoltenVK are:

  • Remove the submodules of SPIRV-Tools and SPIRV-Headers
  • Change the "make*" scripts in External so that they:
    • Don't build SPIRV-Tools (essentially remove these)
    • Call glslang's update_glslang_sources.py as part of the glslang build scripts
  • Update any paths in the MoltenVK Xcode projects to point to the new build locations
    • Example: External/SPIRV-Tools/build/extension_enum.inc would now be found in External/glslang/build/External/spirv-tools.

I'd be happy to submit a PR for this. But I wanted to get Bill's and others' thoughts on this.

Metal Validation error when using a renderpass subpass with no depth attachment

Running with Metal API Validation I see the following warning:

validateDepthStencilState:3657: failed assertion `MTLDepthStencilDescriptor sets depth test but MTLRenderPassDescriptor has a nil depthAttachment texture'

This appears to happen when the renderpass subpass has no depth attachment, but the depth/stencil state in the VkCreateGraphicsPipelineInfo has a non-always depth test or depth write enable (I'm actually not sure which one it is).

vkCmdCopyBuffer requires copy sizes to be a multiple of 4 on macOS

When calling vkCmdCopyBuffer under MoltenVK, each of the regions given needs to have a copy size that is a multiple of 4. Now, I understand that this is a limitation of Metal on macOS, but the Vulkan spec does not indicate there is any such limitation. Additionally, MoltenVK doesn't detect anything wrong and attempts to call the blit command encoder with unchanged parameters and triggers validation errors:

-[MTLDebugBlitCommandEncoder copyFromBuffer:sourceOffset:toBuffer:destinationOffset:size:]:898: failed assertion `size(30) must be a multiple of 4 bytes.'

I have a couple of questions:

  • Is this considered "a bug" from MoltenVK's side? I understand that there may be things in the Vulkan API that cannot be emulated with full fidelity, although this seems to be one that can be worked around (even if it would be very roundabout and complicated).
  • If not, is there a list of such discrepancies or instances where behavior is different from the spec?

Feature request: support VkPipelineCache with MSL shaders

Source 2 caches compiled shaders by retrieving cached VkPipelineCache with vkGetPipelineCacheData and loading pipeline cache with VkPipelineCacheCreateInfo.pInitialData. Since MoltenVK at runtime converts from SPIR-V to MSL, it would be ideal if it could store the generated MSL inside of a VkPipelineCache (hashed on the SPIR-V to avoid subsequent conversions).

Ideally the VkPipelineCache would store Metal shader binaries, but as I understand it there is no way to reflect this at runtime so it seems caching the MSL is the best that can be done for now.

vkCmdBlitImage only supports identical formats and is shifted

MVKCmdBlitImage::setContent restricts vkCmdBlitImage to images with the same format:

   if (_srcImage->getMTLPixelFormat() != _mtlPixFmt) {
        setConfigurationResult(mvkNotifyErrorWithText(VK_ERROR_FEATURE_NOT_PRESENT, "vkCmdBlitImage(): The source and destination images must have the same format."));
    }

But vkCmdBlitImage can be used with formats with different pixel formats in some cases, the rules in the spec are:

"The following filtering and conversion rules apply:

Integer formats can only be converted to other integer formats with the same signedness.

No format conversion is supported between depth/stencil images. The formats must match.

Format conversions on unorm, snorm, unscaled and packed float formats of the copied aspect of the image are performed by first converting the pixels to float values.

For sRGB source formats, nonlinear RGB values are converted to linear representation prior to filtering.

After filtering, the float values are first clamped and then cast to the destination image format. In case of sRGB destination format, linear RGB values are converted to nonlinear representation before writing the pixel to the image."

This causes viewport scaling as well as post process filtering (i.e. when pausing with F9) in dota not to work. Additionally, there is a bug with shifted blits when using the rendering blit path.

Scissor rect needs to be clamped to viewport width

We use static scissor and dynamic viewport configuration when creating the pipeline state:

VkRect2D scissor = {};
scissor.offset.x = 0;
scissor.offset.y = 0;
scissor.extent.width = 16384;
scissor.extent.height = 16384;

VkPipelineViewportStateCreateInfo viewportState = {};
viewportState.sType = VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO;
viewportState.viewportCount = 1;
viewportState.pViewports = nullptr; // dynamic
viewportState.scissorCount = 1;
viewportState.pScissors = &scissor;

In MoltenVK, with this setup we get a Metal validation error when trying to use this with a correctly sized viewport:

-[MTLDebugRenderCommandEncoder setScissorRect:]:2565: failed assertion `(rect.x(0) + rect.width(16384))(16384) must be <= render pass width(256)'

I believe what should happen is that the scissor rect from the pipeline state should be clamped to viewport dimensions.

Contribution Guidelines

I'm interested in fixing some of the issues I encountered (separate issues filed), but I don't see any information regarding external contributions. A few questions:

  • Are contributions accepted? I assume there is some sort of CLA process that likely needs to be followed, but I'm not sure. I think the answer to the above is "yes", but I guess I'm more interested in the specifics of the process.
  • Are there any validation tests I can run? Obviously I'm interested in fixing the code so that my rendering library works on top of it, but that won't give very broad coverage.
  • What's the best way to get questions answered about the implementation and/or the best approach for a fix? Discussing things in individual issues works fine for me, but I'm not sure if there are other channels that are more convenient.
  • Are there more technical docs available anywhere? The docs in here are mostly end-user docs rather than for devs working on MoltenVK itself.

Thanks for all of the work on this library, I'm looking forward to using it!

Request for compatibility with current Vulkan PC games

Just asked also in this Vulkan->D3D12 wrapper:
msiglreith/rostkatze#3
so why not here also..
of course this is for when we have wine Vulkan support for MacOS:
I asked for support to the guy who is adding Vulkan support into Wine these days:
(roderickc/wine-vulkan#8)

when this support is in place I'm creating this issue to see how as MoltenVK matures how becomes able to run current PC Vulkan games.
no pressure of course.. just please keep it open..
I'm thinking primarily about:
*vkquake
*Doom 2016
*Wolfenstein II
*Dota 2
*Talos principle
*Ashes singularity

Using MVKImage's getLayerCount() to initialize layerCount of an MVKImageView's subresourceRange breaks down for 3D images with 3D image views.

MVKImage's getLayerCount() function effectively treats a 3D texture as a 2D texture array and returns a count > 1 for such textures. This is useful in certain scenarios, such as calculating the total size occupied by a buffer that would hold the raw bytes of a 3D texture (such as in MVKImage's constructor) or an offset into such a buffer (such as in MVKImage::initSubresourceLayout()).

During construction of an MVKImageView, the layerCount member of its subresourceRange object is initialized in part using a call to this function, if the subresourceRange.layerCount of the incoming VkImageViewCreateInfo is VK_REMAINING_ARRAY_LAYERS. This breaks down for 3D images with 3D image views because the layerCount will be > 1 for such image views, which is invalid, and causes an assertion failure in the call to MTLTexture's newTextureViewWithPixelFormat in MVKImageView::newMTLTexture().

The same should be true for MVKImage::applyImageMemoryBarrier, if the vkCmdPipelineBarrier that triggers it is passed a VkImageMemoryBarrier that has VK_REMAINING_ARRAY_LAYERS for its subresourceRange.levelCount. I believe that would cause a validation failure in BlitCommandEncoder's synchronizeTexture.

MoltenVK (or Metal) supports half floats on desktop profile? (vulkan_minimal_compute works ok but not with minor modifications for fp16 usage)

Hi,
testing this simple compute Mandelbrot sample:
https://github.com/Erkaman/vulkan_minimal_compute
works ok with the default shader..
i.e. loads comp.spv from shader folder and generates as result of running compute shader a png as output showing Mandelbrot fractal..
I changed minimally the shader computation to use float16 ops:

#extension GL_AMD_gpu_shader_half_float: enable
#define vec2 f16vec2

as main computation is done in vec2 variables..
regenerated SPIR-V comp.spv as glslangValidator supports f16vec2 using when using GL_AMD_gpu_shader_half_float..
generated SPIR-V looks good, has things like:

           OpCapability Float16
               OpExtension "SPV_AMD_gpu_shader_half_float"
               %half = OpTypeFloat 16
               %v2half = OpTypeVector %half 2
               %92 = OpLoad %half %91
                %93 = OpFMul %half %90 %92
                %94 = OpFSub %half %88 %93.
                OpFAdd %v2half %105 %106

assuming Metal shader output that gets used by MoltenVK is similar to SPIRV-Cross I get good looking code ( in the sense that original vec2 operations are now half2 ops):
spirv-cross comp.spv --msl:

    float x = float(gl_GlobalInvocationID.x) / 3840.0;
    float y = float(gl_GlobalInvocationID.y) / 2160.0;
    half2 uv = half2(half(x), half(y));
    float n = 0.0;
    half2 c = half2(6.5690069410618774650762595405465e-41, 0.0) + (half2(float2(uv) - float2(0.5)) * half2(2.3202699972290321060355114440114e-41));
    half2 z = half2(0.0);
    for (int i = 0; i < 128; i++)
    {
        z = half2((z.x * z.x) - (z.y * z.y), half((2.0 * float(z.x)) * float(z.y))) + c;
        if (float(dot(z, z)) > 2.0)
        {
            break;
        }
        n += 1.0;
    }

I'm running the program with standard val debug layers enabled..

for whatever reason need to use

VK_LAYER_PATH=/etc/vulkan/explicit_layers.d ./vulkan_minimal_compute

to find the layers..

Debug Report: SC: SPIR-V module not valid: Using a 16-bit floating point type requires the Float16 or Float16Buffer capability, or an extension that explicitly enables 16-bit floating point.

but we should not look it carefully as running spirv-val comp.spv on that modified 16bit SPIR-V returns no errors..
and seems there were float16 related bugs up to very recently on SPIRV-Tools:
KhronosGroup/SPIRV-Tools#1375
KhronosGroup/SPIRV-Tools#1376
so asking two things:

  1. are halfs generated by SPIRV-Cross and compiled by Metal Shader compiler supported on MacOS
    desktop or are only for mobile? note I'm checking on a RX Vega that has native fp16 support..
  2. MoltenVK has to fix something to support half support?

README.md should include an intro on running the demos

The demo example projects fail to build, seemingly due to some missing files.

Steps to reproduce:

  1. git clone with --recursive
  2. run MoltenVK/External/buildAll
  3. Open MoltenVKPackaging Xcode project
  4. Run the aggregate target MoltenVK (Debug) to build everything
  5. Open Demos.xcworkspace in MoltenVK/Demos
  6. Try to run any of the demos, all fail to build with missing file errors.

Example from Cube-macos demo:

error: /Users/someuser/dev/MoltenVK/Demos/LunarG-VulkanSamples/VulkanSamples/demos/cube-vert.spv: No such file or directory

MVKScissorCommandEncoderState::encodeImpl Metal Validation error with scissor extending beyond renderpass bounds

I have a framebuffer with resolution 1280x720 and the application is setting a scissor with a width of 1292x23. This passes Vulkan validation so I believe it is valid to do. However, Metal Validation gives the following error in MVKScissorCommandEncoderState::encodeImpl:

-[MTLDebugRenderCommandEncoder setScissorRect:]:2565: failed assertion `(rect.x(0) + rect.width(1292))(1292) must be <= render pass width(1280)'

Does MoltenVK need to clamp the scissor to the renderpass width/height?

vkquake compiles ok but fails to launch under MacOS..

I tried vkquake available here:
https://github.com/Novum/vkQuake

this is mostly copy&paste from:
Novum/vkQuake#132

so tried to compile vkquake using MacOS Vulkan SDK and to my surprise compiled ok changing only libvulkan.so for -framework vulkan on Makefile..
I did previously:
brew upgrade libsdl
to use also new SDL 2.0.8 supporting Vulkan for Macos..

seems to crash very late in the process of Vulkan init so seems good news:
as said I have reported to vkquake devs asking if it is easy to fix from their side..
errors seems to be:
VkPrimitiveTopology value 5 is not supported for rendering
and shader compiler error:
Compilation failed:

program_source:46:20: error: called object type 'float' is not a function or function pointer
float dot = dot(vertexnormal, ubo.shade_vector);

./vkquake
Command line: ./vkquake
Found SDL version 2.0.8
Detected 4 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.0 (c) Ozkan Sezer, Eric Wasylishen & others
vkQuake 0.97.3 (c) Axel Gneiting & others
Host_Init
Playing shareware version.
Console initialized.
UDP_Init: skipping gethostbyname for iMac-de-oscar.local
UDP Initialized
Server using protocol 666 (FitzQuake)
Exe: 15:55:12 Mar 3 2018
256.0 megabyte heap

Vulkan Initialization
Vendor: NVIDIA
Device: AMD Radeon RX Vega 56
Using D32 depth buffer format
Creating command buffers
Initializing staging
Creating descriptor set layouts
Initializing dynamic vertex buffers
Initializing dynamic index buffers
Initializing dynamic uniform buffers
Initializing samplers
Creating pipeline layouts
Using FIFO present mode
fpCreateSwapchainKHR
Creating color buffer
AA disabled
Creating depth buffer
Creating render passes
Creating frame buffers
Creating pipelines
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 5 is not supported for rendering.
[MoltenVK ERROR] VK_ERROR_INITIALIZATION_FAILED: Shader module compilation failed (code 3):

Compilation failed:

program_source:46:20: error: called object type 'float' is not a function or function pointer
float dot = dot(vertexnormal, ubo.shade_vector);
~~~^

-[MTLRenderPipelineDescriptorInternal validateWithDevice:]:2149: failed assertion `vertexFunction must not be nil.'
Abort trap: 6

ReadMe links broken

The README.md document contains links to two ThirdPartyConfig.md documents that have been combined into one and moved. These links need to be repaired.

Vulkan grass rendering project doesn't launch..

Ok,
had this project on a Mac drive compiled with MoltenVK 0.19.0..
https://github.com/CIS565-Fall-2017/Project6-Vulkan-Grass-Rendering
it's a nice sample and also nice because another simple portable app due to GLFW usage I compiled GLFW current master which MacOS Vulkan support enabled and perhaps some minimal fixes had to be done don't remember but can post my current source code if needed to reproduce..

good news seems ABI hasn't changed vs current open source 1.0.0 yet as I pointed to new libMoltenVK.dylib and launched..
seems shows same errors as 0.19.0:

VkPrimitiveTopology value 10 is not supported for rendering.

also then there is some shader compiler error that maybe perhaps a thing to look to SPIRV-Cross devs right? as seems the error is from Metal Shader compiler..

VK_ERROR_INITIALIZATION_FAILED: Could not create render pipeline:
Error Domain=CompilerError Code=1 "Link failed: The type of fragment input user(locn1) does not match the type of the corresponding vertex shader output" UserInfo={NSLocalizedDescription=Link failed: The type of fragment input user(locn1) does not match the type of the corresponding vertex shader output}.

it's strange because shader code was not modified and worked on some 3 different native Vulkan drivers I tested..

Also one change I note from MoltenVK 0.19 to 1.0 version is lack of "mvk-info" output strings which can be nice when debugging.. is there any env variable to force old behaviour?

[mvk-info] MoltenVK version 0.19.0. Vulkan version 1.0.64.
[mvk-info] GPU device AMD Radeon RX Vega 56 supports the following Metal Feature Sets:
	OSX GPU Family 1 v3
	OSX GPU Family 1 v2
	OSX GPU Family 1 v1
[mvk-info] Created 2 swapchain images with initial size (640, 480).

Full logs
below:

using MoltenVK 1.0.0:

512 512 images/grass.jpg[***MoltenVK ERROR***] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 10 is not supported for rendering.
[***MoltenVK ERROR***] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 10 is not supported for render pipelines.
[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: Could not create render pipeline:
Error Domain=CompilerError Code=1 "Link failed: The type of fragment input user(locn1) does not match the type of the corresponding vertex shader output" UserInfo={NSLocalizedDescription=Link failed: The type of fragment input user(locn1) does not match the type of the corresponding vertex shader output}.
terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed to create graphics pipeline

Full log using MoltenVK 0.19.0:

[mvk-info] MoltenVK version 0.19.0. Vulkan version 1.0.64.
[mvk-info] GPU device AMD Radeon RX Vega 56 supports the following Metal Feature Sets:
	OSX GPU Family 1 v3
	OSX GPU Family 1 v2
	OSX GPU Family 1 v1
[mvk-info] You require a license for the MoltenVK Vulkan Core feature set. Reverting to evaluation mode.
[mvk-info] Created 2 swapchain images with initial size (640, 480).
512 512 images/grass.jpg[***MoltenVK ERROR***] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 10 is not supported for rendering.
[mvk-info] Shader module compilation succeeded with warnings (code 4):

Compilation succeeded with: 

program_source:32:11: warning: unused variable 'lambert'
    float lambert = clamp(abs(dot(normalize(in.f_normal.xyz), normalize(lightDir))), 0.0, 1.0);
          ^

[***MoltenVK ERROR***] VK_ERROR_FORMAT_NOT_SUPPORTED: VkPrimitiveTopology value 10 is not supported for render pipelines.
[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: Could not create render pipeline:
Error Domain=CompilerError Code=1 "Link failed: The type of fragment input user(locn1) does not match the type of the corresponding vertex shader output" UserInfo={NSLocalizedDescription=Link failed: The type of fragment input user(locn1) does not match the type of the corresponding vertex shader output}.
terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed to create graphics pipeline

Incorrect texture format being used for framebuffer pixel format

Dota 2 creates mutable textures that are views with sRGB and UNORM image views. When rendering to a UNORM view of an sRGB texture, I get the following validation error:

-[MTLDebugRenderCommandEncoder validateFramebufferWithRenderPipelineState:]:1196: failed assertion `For color attachment 0, the render pipeline's pixelFormat (MTLPixelFormatRGBA8Unorm) does not match the framebuffer's pixelFormat (MTLPixelFormatRGBA8Unorm_sRGB).โ€™

This also results in rendering artifacts (blown out bloom):

screen shot 2018-01-12 at 9 07 20 am

MoltenVKShaderConverter fails to link in Release

Xcode 9.2 I get the below link error in the Release version of the project. I can workaround it by adding FileSupport.mm to "Compile Sources" in the MoltenVKShaderConverter.xcodeproj, but then it causes a link error with Debug.

It's maybe an issue with visibility of symbols across static libraries being different in Debug vs Release?

Ld /Users/dang/Library/Developer/Xcode/DerivedData/MoltenVKPackaging-bgddvpmgotkjdtcnztujiyrtyhzy/Build/Products/Release/MoltenVKShaderConverter normal x86_64
cd /Users/dang/src/MoltenVK-danginsburg/MoltenVKShaderConverter
export MACOSX_DEPLOYMENT_TARGET=10.9
/Applications/Xcode_9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode_9.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/Users/dang/Library/Developer/Xcode/DerivedData/MoltenVKPackaging-bgddvpmgotkjdtcnztujiyrtyhzy/Build/Products/Release -F/Users/dang/Library/Developer/Xcode/DerivedData/MoltenVKPackaging-bgddvpmgotkjdtcnztujiyrtyhzy/Build/Products/Release -filelist /Users/dang/Library/Developer/Xcode/DerivedData/MoltenVKPackaging-bgddvpmgotkjdtcnztujiyrtyhzy/Build/Intermediates.noindex/MoltenVKShaderConverter.build/Release/MoltenVKShaderConverter.build/Objects-normal/x86_64/MoltenVKShaderConverter.LinkFileList -mmacosx-version-min=10.9 -stdlib=libc++ -fobjc-link-runtime -ObjC -framework MoltenVKGLSLToSPIRVConverter -framework MoltenVKSPIRVToMSLConverter -Xlinker -dependency_info -Xlinker /Users/dang/Library/Developer/Xcode/DerivedData/MoltenVKPackaging-bgddvpmgotkjdtcnztujiyrtyhzy/Build/Intermediates.noindex/MoltenVKShaderConverter.build/Release/MoltenVKShaderConverter.build/Objects-normal/x86_64/MoltenVKShaderConverter_dependency_info.dat -o /Users/dang/Library/Developer/Xcode/DerivedData/MoltenVKPackaging-bgddvpmgotkjdtcnztujiyrtyhzy/Build/Products/Release/MoltenVKShaderConverter

Undefined symbols for architecture x86_64:
"mvk::absolutePath(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from:
mvk::MoltenVKShaderConverterTool::convertGLSL(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, MVKShaderStage) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::processFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::convertSPIRV(std::__1::vector<unsigned int, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, bool) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::parseArgs(int, char const**) in MoltenVKShaderConverterTool.o
bool mvk::iterateDirectorymvk::MoltenVKShaderConverterTool(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, mvk::MoltenVKShaderConverterTool&, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&) in DirectorySupport.o
"mvk::pathExtension(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from:
mvk::MoltenVKShaderConverterTool::convertGLSL(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, MVKShaderStage) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::processFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) in MoltenVKShaderConverterTool.o
"mvk::lastPathComponent(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from:
mvk::MoltenVKShaderConverterTool::convertGLSL(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, MVKShaderStage) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::convertSPIRV(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::convertSPIRV(std::__1::vector<unsigned int, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, bool) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::parseArgs(int, char const**) in MoltenVKShaderConverterTool.o
"mvk::pathWithExtension(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >)", referenced from:
mvk::MoltenVKShaderConverterTool::convertGLSL(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, MVKShaderStage) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::convertSPIRV(std::__1::vector<unsigned int, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, bool) in MoltenVKShaderConverterTool.o
"mvk::readFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::vector<char, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&)", referenced from:
mvk::MoltenVKShaderConverterTool::convertGLSL(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, MVKShaderStage) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::convertSPIRV(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&) in MoltenVKShaderConverterTool.o
"mvk::writeFile(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, std::__1::vector<char, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&)", referenced from:
mvk::MoltenVKShaderConverterTool::convertGLSL(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, MVKShaderStage) in MoltenVKShaderConverterTool.o
mvk::MoltenVKShaderConverterTool::convertSPIRV(std::__1::vector<unsigned int, std::__1::allocator > const&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >&, bool) in MoltenVKShaderConverterTool.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Multiple errors when trying to use cubemap rendertargets

We are getting Metal validation errors when trying to:

  • render to a cubemap (one face at a time, using image view with VK_IMAGE_VIEW_TYPE_2D and subresourceRange.baseArrayLayer 0..5)
  • generate mipmaps for a cubemap (by blitting from face to face)

For the first issue, we get this Metal error:

validateAttachmentOnDevice:267: failed assertion `Slice is 1, but the texture has only 1 slices'
durring vkCmdBeginRenderPass

For the second issue, we get this Metal error:

validateFunctionArguments:3377: failed assertion `Fragment Function(fragCmdBlitImageF): incorrect type of texture (MTLTextureType2DArray) bound at texture binding at index 0 (expect MTLTextureType2D) for texture[0].'
from vkCmdBlitImage

It looks like the texture that we create is somehow classified as either a 2D texture or maybe a texture array instead of a cube texture? We create the texture with VK_IMAGE_TYPE_2D, arrayLayers=6 and VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT flag; after this we create the image view with type VK_IMAGE_VIEW_TYPE_CUBE; after this we create 6 image views with type VK_IMAGE_VIEW_TYPE_2D (to render into each individual face).

Feature request: Combine MTLCommandBuffers where possible

There is anecdotal and some experimental evidence that reducing the quantity of individual MTLCommandBuffers can improve overall rendering performance.

Refactor MoltenVK handling of MTLCommandBuffers to see if there are opportunities to combine them across queue submissions.

Build failure without asciidoctor

I realized that the build instructions say that asciidoctor is needed but afaik it is just used to generate documentation, which certainly is not always required.

So some way to successfully build without the documentation seems like it should exist.

Feature request: VK_KHR_maintenance1

There are two aspects of VK_KHR_maintenance1 that source 2 has relied on:

  • Viewport inversion
  • vkAllocateDescriptorSets failing with VK_ERROR_OUT_OF_POOL_MEMORY_KHR

I have recently removed the reliance on viewport inversion, but the engine still does rely on vkAllocateDescriptorSets failing when pool memory is exceeded.

We can get by without these two features, but adding maintenance1 support would be convenient.

Build Failure: Please Update SPIRV-Tools (and other) Submodules

The brew package manager for macOS recently changed the way it configures Python so that Python 3 is now the default.

This had the odd consequence of not being able to build SPIRV-Tools at the current submodule commit due to a Python script that had a mix of tabs and spaces in it. Python 3 is less tolerant of this than Python 2.

The problem with the Python script was fixed with this commit.

So we need the MVK repo to point to the SPIRV-Tools submodule at that commit or later.

It would probably be good to review the other submodules as well.

About Glsl.Std.450 support

When porting rpcs3 to mvk, one of the major challenges was that some functions that are part of the spir-v extended functions for glsl are not supported e.g unpackHalf2x16. Is it a bug or are is it safe to assume none of the glsl extensions are implemented?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.