Cool! Please file SPIRV-Cross issues if you have shader compilation issues. Seems like a good torture test.

Otherwise, it looks in the application bundle directory, under DolphinWx.app/Contents/MacOS/libMoltenVK.dylib. Please let me know if this is not the appropriate location for shared libraries on macOS

I'm just a random person who stumbled upon this thread, but I think a better place for this would be Dophin.app/Contents/Frameworks, to be in line with the rest of the libraries Dolphin depends on. Also, minor nitpick: you include both <objc/runtime.h> and <objc/message.h> in SwapChain.cpp, but you can get away with just <objc/message.h> since it includes the other.

@HansKristian-ARM Will do. I'll probably dig into it a bit further, in case it is an issue on our end.

@saagarjha Thanks for the advice. The bundle programming guide seems to support placing it in Contents/Frameworks. I probably should've checked this first!

👍

• Framerate still may be limited at the refresh rate, despite MoltenVK setting the requisite flag, and exposing IMMEDIATE present mode.

It appears that it was a bug in MoltenVK: KhronosGroup/MoltenVK#171

We're hitting a bug in MoltenVK which is causing "random" pipelines to fail to create. I've added a workaround in this branch, but before this is merged, I would like to remove it.

I've opened an issue in MoltenVK, so hopefully it can fixed upstream.

Apple is deprecating OpenGL in macOS 10.14 so this is a great addition

I am glad to hear your success in getting this as far as you have. I was looking into doing the same thing once OpenEmu had a metal Renderer. I currently have Dolphin ported to OpenEmu with decent results using OpenGL.

I’m linking issues KhronosGroup/MoltenVK#61, KhronosGroup/MoltenVK#113 and KhronosGroup/MoltenVK#123, as they may or may not be relevant.

And if they’re not, at least you now know about them and the relevant forum thread (in which you can post about this PR).

Pipeline creation fix is in MoltenVK, so this should be good for review/merge now. Ubershaders are still broken due to what appears to be a SPIRV-Cross bug (doesn't like accessing the shader inputs in a function other than main), but that's a separate issue.

Hello! Sorry, but I'm having a bit of a problem: I built your moltenvk branch, however as soon as I try to start a game with the Vulkan renderer it crashes with this error:
-[MTLRenderPipelineDescriptorInternal validateWithDevice:]:2400: failed assertion `No valid pixelFormats set.'

Full crash log: https://pastebin.com/JiTxc9TN

Thanks in advance!

@Ichicoro are you using a recent MoltenVK build? I vaguely recall an error like this being fixed upstream.

@stenzek I'm using the MoltenVK dylib from the LunarG Vulkan SDK 1.1.73.0. Should I compile it myself instead of using the prebuilt library?

edit: I also forgot to mention that setting LIBMOLTENVK_PATH doesn't do anything: Dolphin keeps saying that it can't load the Vulkan backend. The only way to get it to work is by dropping the dylib(s?) in the DolphinWx.app/Contents/Frameworks dir

Yeah, try building it yourself. Not sure how old that version is.
Edit: There aren't prebuilt binary builds of the latest version, annoyingly. I'm still hoping we can integrate this into our buildbot process somehow.

LIBMOLTENVK_PATH=/path/to/dylib ./dolphin-emu should work, see https://github.com/dolphin-emu/dolphin/pull/7039/files#diff-318a610c8b33f6d16b4302b84222af08R121

@stenzek, I can't build MoltenVK right now, because I have literally no space on my macOS partition. Do you have any idea where I could get a prebuilt binary of the latest version? The website seemingly doesn't have the latest SDK.

@stenzek Great work so far! I'm pretty curious to try this out, so I just grabbed your branch, rebased on upstream master, and successfully compiled everything (Release). I also grabbed the latest MoltenVK master of this morning, built that (Release), and set the LIBMOLTENVK_PATH environment variable. However, I've only managed to see correct video out of the system once while fiddling with it. Rendering stats appear correct, but the output window typically remains a grey box and the log shows pipeline creation failures.

Do you suspect that I've configured something incorrectly? This is on a late-2016 15" MBP with 10.13.5.

@mbutrovich Try running it in a terminal and checking the output log. If I remember correctly, compile errors should show there, even if it's a release build. Otherwise, you may need a debug build (debug build for MoltenVK, that is).

Also, please make sure you do not have ubershaders enabled, as these currently fail in the SPV->MSL translation.

@stenzek I grabbed a log of terminal output. I had Shader Compilation set to Synchronous and unchecked Compile Shaders Before Starting. Let me know if that's incorrect. Thanks for your help. Please let me know if you'd like me to rerun it with a debug build of MoltenVK or try something different.

@mbutrovich Thanks, that is helpful. I'll look into it when I get a chance next.

Thanks for your work on this!

For what is worth, on an Intel Iris chip, loading a locally-compiled MoltenVK build works, but the graphics initialization fails with:

[mvk-info] MoltenVK version 1.0.12. Vulkan version 1.0.77.
[mvk-info] GPU device:
		model: Intel Iris Graphics
		type: Discrete
		vendorID: 000000
		deviceID: 000000
		pipelineCacheUUID: 00000000-0000-0000-0000-27110000271C
	supports the following Metal Feature Sets:
		macOS GPU Family 1 v2
		macOS GPU Family 1 v1
[mvk-info] MoltenVK version 1.0.12. Vulkan version 1.0.77.
[mvk-info] GPU device:
		model: Intel Iris Graphics
		type: Discrete
		vendorID: 000000
		deviceID: 000000
		pipelineCacheUUID: 00000000-0000-0000-0000-27110000271C
	supports the following Metal Feature Sets:
		macOS GPU Family 1 v2
		macOS GPU Family 1 v1
[mvk-info] Created VkDevice to run on GPU Intel Iris Graphics
[mvk-info] Created 2 swapchain images with initial size (1116, 738).
[***MoltenVK ERROR***] VK_ERROR_FEATURE_NOT_PRESENT: Texel buffers are not supported on this device.
[***MoltenVK ERROR***] VK_ERROR_FEATURE_NOT_PRESENT: Texel buffers are not supported on this device.
[***MoltenVK ERROR***] VK_ERROR_FEATURE_NOT_PRESENT: Texel buffers are not supported on this device.
[***MoltenVK ERROR***] VK_ERROR_FEATURE_NOT_PRESENT: Texel buffers are not supported on this device.
[***MoltenVK ERROR***] VK_ERROR_FEATURE_NOT_PRESENT: Texel buffers are not supported on this device.
[1]    27766 segmentation fault  LIBMOLTENVK_PATH= Binaries/Dolphin.app/Contents/MacOS/Dolphin

But I guess its expected that Intel chips are more difficult to support (if they are ever supported at all
¯\(ツ)/¯ )

@kemenaran Are you using macOS 10.13? IIRC texel buffers are added in the macOS GPU Family 1 v3, which the log claims your device does not support.

That said, we probably shouldn't assume presence of texel buffers in the first place..

@stenzek oh right, I'm using macOS 10.12 (and not 10.13). So it's expected, indeed. I'll see if I can check on 10.13 at some point later.

Built the latest MVK (v1.0.10) and finally got it to show graphics. Seems like two more options conflict with MoltenVK at the moment:

• Enabling GPU texture decoding crashes Dolphin with this error:
  MTLTextureDescriptor has width (4194304) greater than the maximum allowed size of 16384.

• Enabling Force 24 Bit color Scaled EFB copy gives me an empty render window

Running the build from here using macOS 10.13.5 and a GeForce GT 750M.

Does it show anything useful without those two options enabled?

Looks like you have to disable the 24 Bit Color option, start a game, close it and start it again in order to show graphics. As soon as the render window loses focus, it turns grey, trying to close it freezes Dolphin.

Wind Waker goes ingame without any glitches so far, performance-wise it might be a tick better than OpenGL. Mario Sunshine freezes the emulator, Twilight Princess crashes Dolphin with the texture descriptor error when loading my save from the Twilight realm going ingame (the intro plays fine).

Can you try a game like Paper Mario: The Thousand Year Door, that could really benefit performance wise thanks to macOS not supporting modern OpenGL features. My guess is that it'll crash, but, maybe not.

Sounds like EFB2RAM isn't working based on your last two comments.

Twilight Princess crashes Dolphin as soon as you load a save or start a new game. The title screen works as expected.

Paper Mario TYD freezes internally right before the Prologue chapter screen (after the ship crosses from left to right and the screen turns white). It's possible to stop emulation at that point.

Performance-wise, cranking up internal resolution to 5K makes the game actually run slower on Vulkan than on OpenGL. Not sure if I screwed something up during build Built MVK again with recommended flags, nothing changes.

Unchecking EFB2Texture Only doesn't produce any additional crashes in other games, by the way. Any other games to test this on? Mario Kart Double Dash works perfectly.

By the way: I can't find an option to disable multithreading (mentioned in the OP) anywhere. Where should I look?

@pizuz the option was never added to the Qt gui for some reason..

Speaking of Qt, this PR is currently stalled until I figure out:

1. Why the swap chain fails to get a drawable on the Qt frontend (solved)
2. Why Qt draws the window background over the Metal surface

Neither of these happened on Wx, so it's either a Qt issue, or a DolphinQt issue. I'll keep digging when I have time.

@stenzek Manually setting BackendMultithreading = False in GFX.ini doesn't change a thing performance-wise. At least not on my computer (i7 quad core in a late 2013 iMac).

Just in case that'll help somebody trying to follow the initial description, it looks like the file you need to copy to the package is expected to be named differently than provided in the description according to

It does seem that the env.variable should point to the file, so libMoltenVK.dylib might work, however it might that its name is LIBVULKAN_PATH

Here is what worked for me:

1. Download the latest SDK mentioned in Vulkan: macOS support via MoltenVK #7039 (comment)
2. Extract and grab MoltenVK/macOS/dynamic/libMoltenVK.dylib
3. Copy it to dolphin.app/Contents/Frameworks and rename to libvulkan.dylib
4. Start Dolphin and select Vulkan

@stenzek is that expected or did I miss something?

@boggydigital the SDK version is already packaged as of PR #7597

Beautiful, thank you!

Positive performance delta seems really amazing with change!

@stenzek there seem to be couple problems specific to Vulkan (don't see them on OpenGL). E.g. any anti aliasing option seems to result in a crash and v-sync results in a lower performance. Would it be valuable to capture more details?

If so what's the best way to provide useful information and where - here or new bug reports?

Thank you for this amazing change again! 🙂

MSAA being broken is a known issue. We require 2D Multisample Texture Arrays which aren't available until 10.14 (also not sure if it's been implemented in MVK yet).

I am testing the MoltenVK backend on 2018 15'' MacBook Pro. The audio is playing perfectly, and I've followed the instructions on where to place the MoltenVK dylib and know the SDK is already bundled. However, I only get gray screen in-game. Game is Kirby's Return to Dream Land. No anti-aliasing enabled and either at 4x native or 1x native. Both with Intel UHD 630 and Vega 20 GPU's.

I am testing the MoltenVK backend on 2018 15'' MacBook Pro. The audio is playing perfectly, and I've followed the instructions on where to place the MoltenVK dylib and know the SDK is already bundled. However, I only get gray screen in-game. Game is Kirby's Return to Dream Land with on JIT64. No anti-aliasing enabled and either at 4x native or 1x native.

The same issue on my macbook as well

@goldmastersims Stupid question, have you tried stopping the game and pressing start again? For some reason, I usually have to start games twice. They work the second time.

Have you tried disabling render-to-main-window? The Qt frontend does some shenanigans there, which could cause issues with the metal layer.

@goldmastersims Stupid question, have you tried stopping the game and pressing start again? For some reason, I usually have to start games twice. They work the second time.
In my case, restarting did not work.

Have you tried disabling render-to-main-window? The Qt frontend does some shenanigans there, which could cause issues with the metal layer.
The graphics are now displaying. Thanks.

@stenzek the merged PR works for us 🎉 . We published a release for anyone wanting to try gfx-portability with Dolphin: https://github.com/gfx-rs/portability/releases/tag/0.3

Hi @JMC47 @stenzek @Degerz ,
just wanted to say that following discussions here about logic op support in MoltenVK, incredibly (at least for me) is that @cdavis5e has found that altough Metal public API doesn't support logic ops there is private Metal API supporting it and in fact has posted patches for MoltenVK supporting it on this thread:
KhronosGroup/MoltenVK#374
patch:
https://github.com/KhronosGroup/MoltenVK/files/2664894/0001-MVKPipeline-Support-framebuffer-logic-operations.txt
MoltenVK devs note apps using it can't be posted on Apple Store but for a emulator like Dolphin a custom build MoltenVK with logic ops support enabled makes sense, right?

I am having a problem in the 2015 Macbook Pro(i7/Radeon 560X) where the game(New Super Mario Bros) where the load up screen is shown wrong(picture below) and the actual game is colored weirdly and blacked out. Is there a fix to this? I'm running build 9431. Other games have similar problems as well.

Did you enable GPU Texture decoding? Don‘t.

FWIW, it runs fine for me (with or without GPU texture decoding) on Intel Iris 550, using revision 8f2d4c1 with gfx-portability:

Perhaps, it's something about "Radeon 560X" that confuses it.

@pizuz the GPU Texture decoding toggle helped! Thanks!!

@stenzek I just read the november report and got sad to see no single mention of gfx-portability. We were here testing your project, helping as we can to ensure that it targets Vulkan Portability as a standard (as opposed to MoltenVK the library), reporting the games working nicely, and yet whoever reads your report wouldn't even know we exist. And I'm not even talking about benchmarking...

@kvark please feel free to take this up with the article writers. I can't speak for them, but I'm under the impression unless we're focusing on a technical aspect and going in-depth, it tends to lean towards user-facing functionality (we ship mvk alongside, so that's what most users will use).

@kvark

EDIT: Since you emailed us, I'll give you a longer answer. None of us were aware of your work! Like, me and JMC first heard about Vulkan Portability today. So um, it wasn't really possible for us to cover your work in the November Progress Report. Even if we had known, stenzek didn't go with your implementation since it wasn't ready when he was working on this, so back in November when we were writing that article, the impact on our userbase was very low.

As for editing the November Progress Report, there isn't really a reason to do that. Old Progress Reports don't get much readership after the first few days, so we prefer to keep them as time capsules of their development period rather than constantly-updating things. Even if we were to edit in a shout out, at this point no one would see it.

I'm totally open to talking about Vulkan Portability in the future, but we'll need a reason to, something that impacts our userbase. Maybe help us with the frame pacing problems? Dolphin has a built in frametime logging option (Graphics > Log Render Time to File) so getting frametime information out of Dolphin is very easy. If you could help us with that, or even maybe find a way to avoid it in Vulkan Portable, we'd be very interested!

@MayImilae I don't think answering the email here is working out best. Discussing the details of benchmarking and frame-pacing seems slightly off-topic here, especially since the thread has grown big already.

stenzek didn't go with your implementation since it wasn't ready when he was working on this

There isn't any more to do in order to "go with implementation" than swapping one dynamic lib with the other (or changing LIBVULKAN_PATH environment). It's not something that you have to decide up front. gfx-portability was unable to run Dolphin for only about 10 days, out of 6 months this PR was open. Look at the timeline:

• May 31: PR is opened
• Aug 17: me showing up and asking for a few changes, stenzek reporting it doesn't work with gfx-portability out of the box
• Aug 27: posting first screenshots of games working on gfx-portability
• Nov 30: PR is merged

As for editing the November Progress Report

FWIW, I did not suggest to edit the report.

Maybe help us with the frame pacing problems?

I've been looking at the frame times. Filed bug 48871262 to Apple to clarify some of the presentation behavior. It would be great if you provided the exact tools used to analyze the frame times, saves to start off when benchmarking games, any extra scripts used to make the app do the same things between runs, etc.

I don't think answering the email here is working out best. Discussing the details of benchmarking and frame-pacing seems slightly off-topic here, especially since the thread has grown big already.

I really dislike email. If you want you could join us on IRC maybe? But for now, I'll just talk here until someone complains!

It would be great if you provided the exact tools used to analyze the frame times, saves to start off when benchmarking games, any extra scripts used to make the app do the same things between runs, etc.

The tool used was just Dolphin's built in tools, specifically its frametime dumping. As for the method I used, for the test that I showed in the most detail, all I did was loaded up a save of Metroid Prime 2, then recorded 15 seconds of frametimes as I let the game sit. Then I repeated it in MoltenVK and Windows OGL on my desktop. Then of course I put them through a google docs spreadsheet and rendered those graphs. Nothing complicated! There are a few little details though.

*Store EFB Copies to Texture Only must be enabled (EFB to Texture and RAM has explicit sync events that appear to prevent the issue, but that's not a solution as it destroys performance that Macs desperately need)
*Speed Limit: Unlimited (the framelimiter can obfuscate framelimit issues)
*4x native internal resolution (stressing the GPU makes it more apparent, as I talked about in the article)
*Make sure the game window is on screen and in focus
*vsync off (didn't matter in my testing but worth a mention)

Everything else was default and/or not worth noting. Note that the testing I did was around December 1st, so it was done in latest as of that date.

As for the save, here it is. This is for Metroid Prime 2 US, btw. Just run the game, load the first slot (sanctuary fortress), let the animations finish, then start recording 15 seconds of frametimes while the game idles.

01-G2ME-MetroidPrime2.gci.zip

This does mean you'll have to have the game, but, I don't trust a fifolog to reproduce this.

Spent some time figuring out how to load the save... eventually got it with some help from IRC (thanks!).
Here are the results I got using the settings you provided on an Intel-based MacBook with 2 physical CPU cores:

Dolphin-macOS-portability-benchmark.zip

Computed the average and variance of those:

• MoltenVK without backend multi-threading: 15.73 avg, 3.00 variance
• MoltenVK with multi-threading: 15.49 avg, 4.59 variance
• gfx-portability without backend MT: 14.93 avg, 2.32 variance
• gfx-portability with MT: 15.99 avg, 2.18 variance

The measurements are in milliseconds per frame, so lower is better. Overall, variance seems to be fairly sane, unlike the results of November 2018 Report. gfx-portability without MT shows the best result and significantly lesser variance comparing to MoltenVK. I don't think MT is useful in the way it's implemented, and I filed an issue about this.

@MayImilae @stenzek
If that result wasn't convincing enough, I decided to perform the same test on an AMD machine (Radeon Pro 460, as reported by Dolphin) with 4 physical CPU cores. All the same settings and Metroid Prime save file scene, frame times over 20 sec:

Dolphin-macOS-portability-benchmark-AMD.zip

The computed stats show a larger gap between the libraries:

• MoltenVK without MT: mean 18.306593, variance 30.974926
• MoltenVK with MT: mean 18.41038, variance 29.487541
• gfx-portabilityw without MT: mean 14.572058, variance 17.192923
• gfx-portability with MT: mean 14.32026, variance 2.0200737

Again, these are frame times, so lower is better. gfx-portability shows 20% improvement in the average, and completely pins the frame stability when running with backend multi-threading option enabled in Dolphin.

I don't know what else I can do to help. We've just published a release with all the latest improvements: https://github.com/gfx-rs/portability/releases/tag/0.5

@kvark would you mind providing a tutorial on how to use gfx-portability on Catalina ?
I downloaded your last release but don't know where to store the files, nor did I find a file de map it to Dolphin.
And by the way : does portability support bounding box ?

Regards

@DrLuthor you can follow the steps mentioned in #8724

run Dolphin with LIBVULKAN_PATH=/path/to/libportability.dylib /Applications/Dolphin.app/Contents/MacOS/Dolphin

@grovesNL thank you!

@kvark so, I tried portability with 2 games :

• Baten Kaitos, which runs great on the "adventure" screens but displays a gray flat ground on battles
• Paper Mario which is super blinky BUT allow me to pass the scenes where bounding box is used.
  macOS 10.15.4 (19E287)
  Dolphin 5.0-11830

@DrLuthor we were making a new release ready, so fixing this would be quite on time now. Would you mind filing an issue to https://github.com/gfx-rs/portability and providing the repro steps / input logs on the cases that don't work well?