5796b6b158
185: Fixes for gfx HEAD, update Cargo.lock, and add gl backend option r=kvark a=aloucks Updated Cargo.lock and some minor changes to get portability compiling again using the latest gfx master. With these changes I was able to get `vulkaninfo` to run on a GPU-less VM using Mesa. ``` $ RUST_BACKTRACE=1 VK_ICD_FILENAMES=portability-linux-debug.json vulkaninfo > ~/vulkaninfo.txt ========== VULKANINFO ========== Vulkan Instance Version: 1.1.106 Instance Extensions: ==================== Instance Extensions count = 4 VK_EXT_debug_report : extension revision 9 VK_EXT_debug_utils : extension revision 1 VK_KHR_get_physical_device_properties2: extension revision 1 VK_KHR_surface : extension revision 25 Layers: count = 15 ======= ... Device Properties and Extensions : ================================== GPU0 VkPhysicalDeviceProperties: =========================== apiVersion = 0x400042 (1.0.66) driverVersion = 1 (0x1) vendorID = 0x0000 deviceID = 0x0000 deviceType = CPU deviceName = Mesa OffScreen ... ``` Full output: https://gist.github.com/aloucks/1a9acfb51adba4bb598ee6de0a213d82 It's probably a long way from being usable, but it would be nice to use portability for unit testing in CI jobs. See also: https://github.com/gfx-rs/gfx/pull/2791 for updates to the gl backend. Co-authored-by: Aaron Loucks <aloucks@cofront.net> |
||
|---|---|---|
| bench | ||
| conformance | ||
| etc | ||
| libportability | ||
| libportability-gfx | ||
| libportability-icd | ||
| modules | ||
| native | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| appveyor.yml | ||
| bors.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CMakeLists.txt | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
gfx-portability
This is a prototype library implementing Vulkan Portability Initiative using gfx-hal. See gfx-rs meta issue for backend limitations and further details.
Showcase
Dota2:
Quake
RPCS3:
Dolphin:
Instructions
Despite the fact it's written in Rust, the produced binaries have standard lining interface compatible with any program (written in the language of your choice). There are multiple ways to link to gfx-portability.
Dynamic linking
Typically, you'd need to create a symbolic link with a name that a target application expects, e.g. libvulkan.dylib -> libportability.dylib.
Check out and build:
git clone --recursive https://github.com/gfx-rs/portability && cd portability
cargo build --manifest-path libportability/Cargo.toml --features <vulkan|dx12|metal>
ICD provider
gfx-portability can be used with Vulkan loader like any other Vulkan driver. In order to use it this way, you need to build libportability-icd and point to it from an ICD json file:
VK_ICD_FILENAMES=portability/libportability-icd/portability-macos-debug.json <some_vulkan_app>
Static linking
For C, you'd need to add crate-type = ["cdylib"] to libportability-gfx/Cargo.toml and build it with the backend of your choice. Note: features of this library are fully-qualified crate names, e.g. features gfx-backend-metal. For rust, just point the cargo dependency to libportability-gfx.
Running Samples
LunarG (API-Samples)
After building portability as shown above, grab a copy from https://github.com/LunarG/VulkanSamples.
Manually override the VULKAN_LOADER variable and set it to the portability library.
set (VULKAN_LOADER "path/to/portability/library")
Then proceed with the normal build instructions.
Vulkan CTS coverage
Please visit our wiki for CTS hookup instructions. Once everything is set, you can generate the new results by calling make cts on Unix systems. When investigating a particular failure, it's handy to do make cts debug=<test_name>, which runs a single test under system debugger (gdb/lldb). For simply inspecting the log output, one can also do make cts pick=<test_name>.