dynarmic
MoltenVK
dynarmic | MoltenVK | |
---|---|---|
6 | 103 | |
967 | 4,592 | |
- | 2.2% | |
8.8 | 9.0 | |
3 months ago | 9 days ago | |
C++ | Objective-C++ | |
BSD Zero Clause License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dynarmic
- Dynarmic – An ARM dynamic recompiler (AArch32/64 to x86-64/AArch64)
-
RyujinX – Open Source Nintendo Switch Emulator
They're probably referring to dynarmic: https://github.com/merryhime/dynarmic
-
[News] TouchHLE: high-level emulator for iPhone OS apps released
As an HLE, touchHLE is radically different from a low-level emulator (LLE) like QEMU. The only code the emulated CPU executes is the app binary and a handful of libraries; touchHLE takes the place of iPhone OS and provides its own implementations of the system frameworks (Foundation, UIKit, OpenGL ES, OpenAL, etc).
-
Latest news from Emulation regarding Mac
https://github.com/merryhime/dynarmic/pull/697 - Dynarmic implementing Arm backend support. Dynarmic is a dynamic recompiler for ARM.
-
Ryujinx - Progress Report July 2021
I did some work on Dynarmic, so there's my bias I guess. But I def believe Dynarmic would emit better context-aware assembly than a CIL->Native jitteror the JVM would emit. Dynarmic takes advantage of instruction sets like BMI2 and AVX{2,512} and uses a pretty darn concise intermediate representation to the original ARM assembly to emit efficient x86 while a C# JIT probably still only emits baseline x86-64 and struggles with efficient vectorization of things like Arm's NEON instructions. Can't even imagine a C# or Java VM trying to automatically emit optimal assembly for an FMADD including handling NaN propagation or detecting that FMINNM can be very quickly emulated with a single vrangep{s,d} x86 instruction.
-
What are the implications of AVX-512 for emulation?
For emulators, it's currently used in dynarmic(Yuzu's ARM-to-x86 recompiler backend) for the fast emulation of ARM's NEON instruction set.
MoltenVK
- MoltenVK is a layered implementation of Vulkan 1.2
-
Valve Says Counter-Strike 2 for macOS Not Happening, There Aren't Enough Players
https://github.com/KhronosGroup/MoltenVK
Translating between rendering APIs is not really the problem. The GPU design is more different than the API is.
-
Meta Releases Intermediate Graphics Library
Khronos maintains MoltenVk though, which is "official" as it gets: https://github.com/KhronosGroup/MoltenVK
...technically, Vulkan on Windows is also only supported via 3rd-parties (the GPU vendors), Microsoft doesn't support Vulkan either ;)
-
I love the ally, but fuck Windows
MoltenVK implements large parts of Vulkan on top of Metal for Apple systems. It isn't full Vulkan but it makes porting Vulkan games to OS X easier.
- Apple releases a Game Porting Tool, based on open-source platform Wine, which can translate DirectX 12 into Metal 3, a potentially massive step for Mac gaming
- Apple’s Game Porting Toolkit is Wine
-
CrossOver announces DirectX 12 support coming to macOS this summer
That's cool. Maybe I haven't thought enough about this. Let me check it out. FWIW it's this PR that you are referring to I think: https://github.com/KhronosGroup/MoltenVK/pull/1815/
-
Apple Begins Testing Speedy M3 Chips as It Pursues Mac Comeback
For Metal specifically, they could adopt and contribute to Vulkan and get access to a lot more software. Right now you need to use a compatibility layer, and surely Apple could just support both APIs natively with much lower overhead. But they don't, because it nudges developers to stick to the Apple ecosystem instead of being able to support multiple platforms.
-
What do we miss to play DirectX 12 Games on Mac?
At the moment the most promising thing is MoltenVK (DX12 -> DXVK -> Vulkan -> MoltenVK -> Metal), but the development is not that quick mainly because there aren't tons of developer that works at the same time on the project. It's not actually a Metal related problem at the moment (they have a road map of things that they can be achieved with Metal 3 like Mesh shader and Geometry shader).
-
Is there a good reason to not allow vulkan on macos as another option?
What you asked is already existed for at least 8 years. Yeah EIGHT years. It's called "MoltenVK". So far it's the only implementation of Vulkan for macOS. Basically it's a wrapper that runs on top of Metal API.
What are some alternatives?
Ryujinx - Experimental Nintendo Switch Emulator written in C#
DXVK-macOS - Vulkan-based implementation of D3D10 and D3D11 for macOS / Wine
libmorton - C++ header-only library with methods to efficiently encode/decode Morton codes in/from 2D/3D coordinates
metal-cpp - Metal-cpp is a low-overhead C++ interface for Metal that helps developers add Metal functionality to graphics apps, games, and game engines that are written in C++.
asmjit - Low-latency machine code generation
MoltenGL
vvctre - A Nintendo 3DS emulator with Lua scripting for Windows 7+ and Linux (the default script is vvctre folder/script.lua)
FF14-MAC_ModSupport - Alternative method of running FFXIV on Mac with Mod Support.
rpcs3 - PS3 emulator/debugger
dxvk - Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine
ClassicUO - ClassicUO - an open source implementation of the Ultima Online Classic Client.
dxvk-async