MacOS upstreaming roadmap

[riperiperi]

The MacOS build was made using a private tree that we need to upstream in pieces, as there is too much to review all-in-one, and a few things that were a bit messier than they should be on macos.

GPU/UI

• [x] MacOS UI support (#3980)
• [x] Portability Subset, MVK configuration and properly handling limitations (#4202)
  • Many changes to handle portability subset changes and moltenvk specific behaviours. Configuration is required so that environment variables don't need to be set to use argument buffers.
• [x] 16-bit texture conversion (#4108)
  • Metal on intel macs (and rosetta) does not support 16-bit texture formats. Most have a workaround in the version we released, but there are a few missing still. In A64 mode these formats are supported.
• [x] Attachment format specialization (#4202)
  • Attachment output type (float/int) must match the bound attachments on Metal. Technically this is true of Vulkan too, but drivers are typically able to reinterpret the data and get the proper result. With #4004 this change is less expensive, though it will be weird to add as render target state must be checked after shader loading.
• [x] Blend State Fix (#5122)
  • There are a few issues with blend state that need sorting.
  • [x] (#4404)
• [x] Precise Occlusion Queries (#4292)
  • This flag needs to be set to guarantee that occlusion query result is always the number of samples passed. On desktop GPUs it tends to be that regardless, but MVK default is 1/0.
• [ ] Buffer Mirrors (#4899, WIP)
  • Required for good performance under TBDR renderers. Avoids render pass splitting to update buffers as much as possible by uploading to a temporary buffer and generating mirrors in the staging buffer when bindings are committed.
• [ ] TFB-on-SB (https://github.com/Ryujinx/Ryujinx/pull/5080)
  • TFB emulation via storage writes. Required for games that use transform feedback. (pokemon, xenoblade, etc)
• [x] GS-Layer-To-VS (#4368)
  • Required for UE4 games to render correctly.
• [ ] GS-on-VS
  • Geometry shader emulation. If official support were to come via MoltenVK, that would be preferable.
• [ ] MoltenVK Argument Buffers bug workarounds
  • MoltenVK has a ton of issues surrounding storage buffer usage stage flags when running under argument buffers mode. The command buffer immediately fails if the stage usage for any buffer changes between two draws (used in vertex shader only, then in follow up (or in another binding on the same set) used in fragment shader). You'd think that setting the stage flags to always be every stage would work around this issue. However, shaders without a fragment stage or using rasterizer discard force this to happen, and always cause the error. The only way to really solve this is to end the render pass when the stage usage changes due to the program's used stages, and there's a ton of annoying boilerplate we have to do to achieve that. Vulkan should not break when a buffer is used between multiple stages.
  • Need to write a simple vulkan app to reproduce the issue and report to MVK. Simple case is a single draw with two storage bindings to the same buffer with different stage flags (vertex/fragment, others don't matter to mvk). Second case is two draws with different stage flags.

CPU

• [x] ARM64 JIT (#4114)
  • [x] 16kb page workaround mode, and associated changes to memory tracking. (#4252)
• [x] Hypervisor (#4332)
  • Would be nice to identify and fix the weird bug that causes botw and others to crash.

INFRA

• [x] Add macOS (Arm64) to the release CI. (#4837)

There are other smaller things not mentioned here, but this is the jist. I'll check things off as they are PR'd.

[UltraHDR]

FYI: MoltenVK is targetting Q1 '23 for Geometry shaders. https://github.com/KhronosGroup/MoltenVK/discussions/1785#discussioncomment-4257227

[iMonZ]

Can adding to the Homebrew library be on this list?

[gdkchan]

Can adding to the Homebrew library be on this list?

This issue is about upstreaming the changes required to make the emulator work on macOS, I don't think adding it to homebrew is related to that. If you want to request that, it should be a separate issue IMO.

[benjaminmordaunt]

Is there a tracking issue for hypervisor bugs? Like the one that prevents BOTW from booting?

[alessandro893]

Is it possible to make good multithreading? My mac pro use 4 of it's 24 threads, how to fix this bottleneck?

[x4080]

Hi love ryujinx, i wondered why the official Mac os version is more compatible with more games compared to the latest experimental version? For example borderlands 2 and Splatoon 3 works pretty great using official version but crashed for all the experimental versions

[gdkchan]

Hi love ryujinx, i wondered why the official Mac os version is more compatible with more games compared to the latest experimental version? For example borderlands 2 and Splatoon 3 works pretty great using official version but crashed for all the experimental versions

Splatoon 3 hits a stack overflow on SPIRV-Cross because they use recursive function calls. macos1 had a workaround for that by increasing the thread stack size, but I don't want to upstream that since it requires implementing our own thread pool which is not really desirable. I don't have Borderlands 2 so I don't know why it wouldn't work.

[gdkchan]

Borderlands 2 issue is not macOS specific and should be fixed by #5181.

[x4080]

thanks @gdkchan

[cdc42cheng]

Somatosensory operation does not work in HYPERCHARGE: Unboxed and Sniper Eite4

[iMonZ]

Is it possible to add the Sorround sound feature introduced in the May progress report to macOS for the AirPods?

[DamianPereira]

Is there a tracking issue for hypervisor bugs? Like the one that prevents BOTW from booting?

There's this one: https://github.com/Ryujinx/Ryujinx/issues/5219

[Somiona]

Is it possible to sign the macos compiled app so it can be accepted by brew cask for a better mac installation experience? I've created a configuration for Ryujinx (both stable and test), those PR can be accepted by homebrew team if a valid signature is applied!

https://github.com/Homebrew/homebrew-cask-versions/pull/17133

# ryujinx-test.rb
cask "ryujinx-test" do
  version "1.1.960"
  sha256 "e4ed8429f222205bf62b100d5836e05a73c4bd57fc94a5ebb274bc5bd6d33874"

  url "https://github.com/Ryujinx/release-channel-master/releases/download/#{version}/test-ava-ryujinx-#{version}-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-master/"
  name "Ryujinx Test Channel"
  desc "Experimental Nintendo Switch Emulator written in C#, Test Build"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/Library/Application Support/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

https://github.com/Homebrew/homebrew-cask/pull/150933

# ryujinx.rb
cask "ryujinx" do
  version "1.1.0"
  sha256 "259d56bbded1940fb227e01d0e8c0b4ad68dc8f8953f19a6414485427d9c7ae9"

  url "https://github.com/Ryujinx/release-channel-macos/releases/download/#{version}-macos1/Ryujinx-#{version}-macos1-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-macos/"
  name "Ryujinx"
  desc "Experimental Nintendo Switch Emulator written in C#"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/.config/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

[IsaacMarovitz]

Is it possible to sign the macos compiled app so it can be accepted by brew cask for a better mac installation experience? I've created a configuration for Ryujinx (both stable and test), those PR can be accepted by homebrew team if a valid signature is applied!

The issue here is signing and notarisation. Ryujinx is signed with an ad-hoc signature (one which is not considered valid for distribution by Apple's standards) and is not notarized, making it ineligible to be added to mainline homebrew. It is possible for us to create our own tap.

[JC-lurker]

Any chance of native support for motion controls? macOS has nothing working. The cemuhook client sits there without use.

[iMonZ]

Any chance of native support for motion controls? macOS has nothing working. The cemuhook client sits there without use.

Works perfectly fine on me. I got motion controls for the bow etc. the only problem is that it’s very buggy. I get a motion drift and every time I start Ryujinx I need to reset my whole controller settings to get rid of the drift. But after that it works fine. Also for some reason the motion doesn’t work in TOTK the first five minutes after you start the game. After the 5 min phase it works like a charm

[ultratiem]

Any chance of native support for motion controls? macOS has nothing working. The cemuhook client sits there without use.

Works perfectly fine on me. I got motion controls for the bow etc. the only problem is that it’s very buggy. I get a motion drift and every time I start Ryujinx I need to reset my whole controller settings to get rid of the drift. But after that it works fine. Also for some reason the motion doesn’t work in TOTK the first five minutes after you start the game. After the 5 min phase it works like a charm

Try adjusting the dead zone for the sticks as a workaround. Someone else claimed moving the value from .15 fixed any the controls.

[aiyogg]

Could you have a plan to add Intel Macbook Pro with AMD Redon Pro 5300m pro support?

[iMonZ]

Is it possible to sign the macos compiled app so it can be accepted by brew cask for a better mac installation experience? I've created a configuration for Ryujinx (both stable and test), those PR can be accepted by homebrew team if a valid signature is applied!

Homebrew/homebrew-cask-versions#17133

# ryujinx-test.rb
cask "ryujinx-test" do
  version "1.1.960"
  sha256 "e4ed8429f222205bf62b100d5836e05a73c4bd57fc94a5ebb274bc5bd6d33874"

  url "https://github.com/Ryujinx/release-channel-master/releases/download/#{version}/test-ava-ryujinx-#{version}-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-master/"
  name "Ryujinx Test Channel"
  desc "Experimental Nintendo Switch Emulator written in C#, Test Build"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/Library/Application Support/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

Homebrew/homebrew-cask#150933

# ryujinx.rb
cask "ryujinx" do
  version "1.1.0"
  sha256 "259d56bbded1940fb227e01d0e8c0b4ad68dc8f8953f19a6414485427d9c7ae9"

  url "https://github.com/Ryujinx/release-channel-macos/releases/download/#{version}-macos1/Ryujinx-#{version}-macos1-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-macos/"
  name "Ryujinx"
  desc "Experimental Nintendo Switch Emulator written in C#"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/.config/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

Could you also create a formula that would be awesome and doesn't require signing as I know.

[Somiona]

Is it possible to sign the macos compiled app so it can be accepted by brew cask for a better mac installation experience? I've created a configuration for Ryujinx (both stable and test), those PR can be accepted by homebrew team if a valid signature is applied! Homebrew/homebrew-cask-versions#17133

# ryujinx-test.rb
cask "ryujinx-test" do
  version "1.1.960"
  sha256 "e4ed8429f222205bf62b100d5836e05a73c4bd57fc94a5ebb274bc5bd6d33874"

  url "https://github.com/Ryujinx/release-channel-master/releases/download/#{version}/test-ava-ryujinx-#{version}-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-master/"
  name "Ryujinx Test Channel"
  desc "Experimental Nintendo Switch Emulator written in C#, Test Build"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/Library/Application Support/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

Homebrew/homebrew-cask#150933

# ryujinx.rb
cask "ryujinx" do
  version "1.1.0"
  sha256 "259d56bbded1940fb227e01d0e8c0b4ad68dc8f8953f19a6414485427d9c7ae9"

  url "https://github.com/Ryujinx/release-channel-macos/releases/download/#{version}-macos1/Ryujinx-#{version}-macos1-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-macos/"
  name "Ryujinx"
  desc "Experimental Nintendo Switch Emulator written in C#"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/.config/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

Could you also create a formula that would be awesome and doesn't require signing as I know.

I have contacted homebrew team by submitting this PR, and they replied something like this cannot be merged because it failed on signature verification. https://github.com/Homebrew/homebrew-cask-versions/pull/17133#issuecomment-1633452676 So I guess making our own tap for Ryujinx would be better, say a new GitHub repository containing files I posted here.

[iMonZ]

Is it possible to sign the macos compiled app so it can be accepted by brew cask for a better mac installation experience? I've created a configuration for Ryujinx (both stable and test), those PR can be accepted by homebrew team if a valid signature is applied! Homebrew/homebrew-cask-versions#17133

# ryujinx-test.rb
cask "ryujinx-test" do
  version "1.1.960"
  sha256 "e4ed8429f222205bf62b100d5836e05a73c4bd57fc94a5ebb274bc5bd6d33874"

  url "https://github.com/Ryujinx/release-channel-master/releases/download/#{version}/test-ava-ryujinx-#{version}-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-master/"
  name "Ryujinx Test Channel"
  desc "Experimental Nintendo Switch Emulator written in C#, Test Build"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/Library/Application Support/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

Homebrew/homebrew-cask#150933

# ryujinx.rb
cask "ryujinx" do
  version "1.1.0"
  sha256 "259d56bbded1940fb227e01d0e8c0b4ad68dc8f8953f19a6414485427d9c7ae9"

  url "https://github.com/Ryujinx/release-channel-macos/releases/download/#{version}-macos1/Ryujinx-#{version}-macos1-macos_universal.app.tar.gz",
      verified: "github.com/Ryujinx/release-channel-macos/"
  name "Ryujinx"
  desc "Experimental Nintendo Switch Emulator written in C#"
  homepage "https://ryujinx.org/"

  livecheck do
    url :url
    strategy :github_latest
  end

  auto_updates true
  depends_on macos: ">= :big_sur"

  app "Ryujinx.app"

  zap trash: [
    "~/.config/Ryujinx",
    "~/Library/Application Support/CrashReporter/Ryujinx_*.plist",
    "~/Library/Preferences/org.ryujinx.Ryujinx.plist",
    "~/Library/Saved Application State/org.ryujinx.Ryujinx.savedState",
  ]
end

Could you also create a formula that would be awesome and doesn't require signing as I know.

I have contacted homebrew team by submitting this PR, and they replied something like this cannot be merged because it failed on signature verification. Homebrew/homebrew-cask-versions#17133 (comment) So I guess making our own tap for Ryujinx would be better, say a new GitHub repository containing files I posted here.

Dear Ryujinx Team Could you please create a new Repo for https://github.com/Ryujinx/Homebrew

That would be awesome!

[Loweredgames]

fix?

[saraflower]

Dear ryujinx team,

As everything has been merged and there is still one task left, I'm assuming the issues still present on Mac OS are because of such MVK issues, could you let us know if you still have the same plan for that going forward, or are you perhaps waiting for fixes on their side? Any kind of update is greately appreciated. Thanks!

[gdkchan]

AFAIK the argument buffers issue (last bullet point) has already been fixed on latest MoltenVK, but other issues were introduced on MoltenVK since then that affect the emulator, so we can't just update it. The main issue is oclusion query related, it cause objects to flicker. This might not be an issue on MoltenVK side actually, as the way how the emulator does oclusion queries violates the spec in some cases, so it should probably be fixed in the emulator. In the meantime, we can fork MoltenVK and revert the problematic changes (not saying we will do that, but it seems the most simple option right now).

[gdkchan]

This can probably be closed, I confirmed that the InvalidResource errors have been fixed on macOS Sonoma (on my previous comment, I incorrectly assumed that it was fixed by some MoltenVK change, but that doesn't seems to be the case). I don't think it's worth introducing the workarounds just to make it work on old macOS versions. MoltenVK update is being tracked on #5771.