Xenia for Mac? #596
Comments
|
macOS doesn't meet quite a lot of the requirements for xenia. Until it gets an updated openGL driver to support 4.5 or vulkan support (unlikely right now) xenia cannot run on mac. Your best bet would be to dual boot and run xenia on windows. |
|
even with that, there is still a huge amount of porting work needed. For example xenia currently relies on quite a few windows API calls |
|
moltenvk isn't even free.. |
|
^ that too |
|
seems unlikely |
|
xbox means DirectX box. Macs do not have DirectX so I doubt there will ever be a version for Mac. |
|
@Gamedev1909 Are you sure about that? |
|
@MightyElemental but they can write OpenGL/Vulkan driver so it could work on Mac, it is possible, but not worth at actual state of xenia. |
|
There is nothing stopping a OSX build from existing, other than a contributor who would make the necessary effort to get it building on OSX. The main contributors don't develop on OSX. |
|
@gibbed the problem with OS X (at least for now) is awful graphics support. No vulkan and the max OpenGL version is OpenGL 4.2. If mac gets proper graphics drivers I'd be more than happy to attempt to port the rest |
|
Not even 4.2, it's 4.1 on the latest Mac OS. Being a graphics developer on Mac OS is a hard life. Metal definitely has the features to host Xenia, but it'd be better to get the graphics subsystem closer to feature-complete/working before trying to port to yet another hardware backend. |
|
You have no idea what you're talking about. Just stop. |
|
So just contribute to porting Xenia upon OSX. Less wording, more coding. |
|
C'mon, no one has worked on the emu in a month and you want someone to rewrite craploads of code so it runs on a mac? |
|
Does Xenia definitely require features from OpenGL 4.5, or is that the minimum requirement because it's more convenient? Maybe it would be possible to support 4.1 or 4.2 with some smaller scale reworking. |
|
@petmac OpenGL is deprecated. |
|
it seems MoltenVK went open source https://github.com/KhronosGroup/MoltenVK |
Correction: MoltenVK went Opensource |
|
@Gamedev1909 what's the difference between a peice of shit and a peice of shit 2? |
|
They added fan control and overclocking... When Windows and Linux had this for years. Also I do have macOS and OSX and it was a painful experience for me. Drivers barely worked, UI was over simplified to the point where navigating system files was a pain and general usability is horrible for a power user like me. This isn't even bringing up how much of a pain in the ass it is to setup MacOS on non-Apple hardware or even attempting to fix issues with OSX |
|
No offense. But I just think this would be a waste of resources for the
Xenia Team. Its been years and Xenia is still in its early stages and the
team should put as their priority making it emulate Xbox 360 with the most
precision possible so we can play more games on it.
After all most people who use Mac are people who work in graphics design
industry or Web Development. Most hardware and software programmers are
using Linux or Windows as their main OS. Maybe when Xenia gets more stable
the team can look forward in making it avalaible in the platform of good
ol´ narcissistic Steve Jobs. Right now it would be just a waste of
resources and time when the emulator is still in early stages. There are
more important things to fix right now.
On Mon, Feb 26, 2018 at 5:34 PM, Gamedev1909 <[email protected]>
wrote:
… Yet 10.13.4 just changed and overhauled the entire driver set for amd
added fan control and overclocking heck a guy built a app for it again
judge all you want but dont talk shit if you dont have macos
Sent from my iPhone
> On Feb 26, 2018, at 4:31 PM, 0x7FFFFFFF ***@***.***>
wrote:
>
> @Gamedev1909 what's the difference between a peice of shit and a price
of shit 2?
> In this case not much since Apple barely do anything new with newer Mac
OS releases.
> Its just a name and a number.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
—
|
|
this thread got really off topic really quickly... |
|
Since Hackintosh can achieve very high performance hardware spec, when xenia is feature complete, I strongly suggest porting it to MacOS also expecting that I can offer some practical work. |
This is unfortunately true. RPCS3 was able to work around this in RPCS3/rpcs3#5024 |
|
It also doesn't support geometry shaders, which are needed for clear rectangles, and some significant memory usage optimization features used in the new Xenia renderer — sparse resources and heap aliasing. |
|
@Triang3l oh, interesting! I'd like to know more. |
|
@kvark Xenos clear render targets by drawing a large rectangle, however, only 3 vertices are submitted, so we need to reconstruct another one in a geometry shader from the 3 vertices we have, after the vertex shader is done. Regarding the memory-saving features: I was talking about my Direct3D 12 renderer rewrite, but this applies to Vulkan as well. They are optional, but definitely help reduce video memory usage. I'm using a 512 MB buffer to emulate physical memory layout for texture untiling/tiling and vertex fetch because it increases performance (no need to maintain vertex caches) and accuracy (allows for weird render to texture cases, including horizontal predicated tiling). However, games don't necessarily use all those 512 megabytes for textures and vertex buffers, so it's better to allocate that buffer in smaller parts. Resource aliasing is great for render targets since they're transient on the Xbox 360 due to EDRAM. Without aliasing of heap contents, memory would have to be allocated for every used size and format combination, but arbitrary allocation in heaps lets us reuse the memory backing render targets and simply create views of it with different sizes and formats. |
|
What features does Xenia depend on? anything heavily used? |
|
OpenGL is being deprecated, not removed... Yet. |
|
I wanted to share this information I found: https://gamefromscratch.com/cross-platform-opengl-alternatives/. It list libraries that actually sit on top of graphics libraries like Metal, OpenGL, DirectX, and Vulkan. This means writing code once in say bgfx can be used on all supported graphics libraries (cross platform). The ones that impressed me were: |
|
I don't think there's any need for us to give up the ability to do per-API optimizations/fallbacks and to use API-specific extensions and instead adapt to the architecture of somebody's wrapper. On Vulkan, we already have to handle way more device features/limits cases (as we're ultimately targeting not only the PC implementations of Vulkan, but the entire set of Vulkan 1.0-compliant devices, as well as portability subset ones) than on Direct3D in pretty low-level and careful ways, this is basically the primary difficulty of porting to Vulkan. |
|
Metal, in particular, needs certain changes specific to it, such as working around the inability to disable primitive restart. |
So you think the best thing to do is to replace Vulkan with Metal on Mac OS? |
MoltenVK would likely be more of a limitation on macOS, and would probably cause a lot of noise — there are many things that are specific to Vulkan, but not relevant to Metal, and there are parts that are specific to Metal that may need attention. Plus, the current version of MoltenVK translates SPIR-V shader bytecode into the Metal Shading Language — essentially C++ — rather than to the LLVM-ish shader IR directly. This will likely make pipeline state object compilation (mid-game when entering new scenes, at launch when loading the pipeline state cache) around an order of magnitude longer. I remember the early days of working on the Direct3D 12 backend — initially I was translating shaders into HLSL rather than DXBC (which even still has some overhead compared to the more modern, but slightly less widely supported — not on old Intel GPUs and the UWP on the Xbox One — DXIL), and compiling the pipeline state objects for the first frame of Halo 3 took 2 minutes on my PC, rather than a few seconds. When Xenia used GLSL, the situation was roughly the same as well. |
|
Ok so the path to Mac OS compatibility is:
|
|
(not DirectX 9 to be more precise, rather, ATI R400 registers and PM4 packets) Regarding PowerPC translation, I'm not sure if we should even bother creating a new backend for the current IR, or rather, work on it as part of a large-scale rework of the entire recompiler architecture. Also, all the Linux requirements (and potentially on the very low system level, some parts will be different than on Linux even considering that macOS is not running on the Linux kernel), primarily on the Xbox 360 kernel reimplementation side, still apply, as well as macOS implementations of UI, input and audio interfaces. |
|
Well the PowerPC translation issue might not be so important right now. Rosetta 2 can probably handle the current x86 backend. So things would be like this: PowerPC -> xbyak x86_64 -> Rosetta 2 -> M1 CPU. That is a lot of translation but I do believe it can be done. The Xbox 360's hardware is around 17 years old now. Our modern hardware should be able to handle the translation layers and keep up with the games. I do hope to make things simplified in the future. What was your idea for a "rework of the recompiler architecture"? I did some reading here #1430. Looks like sound is implemented using SDL2. Now that I think about it almost everything could be implemented on top of SDL and run on both Mac OS and Windows. |
I'm thinking about making our HIR more PowerPC-like (basically PowerPC code in SSA form and with structured control flow), but with more advanced optimizations (including instruction scheduling) for the host architecture, involving host-specific intermediate representations in addition to the PowerPC frontend one, instead of the current model where we basically have some parts of a compiler on the level of the HIR (which is quite abstract and arbitrary, and pretty far from both PowerPC and x86), but the host backends act roughly as simple translators of the HIR instead. I've written various notes in #2002 (comment) regarding this. |
|
With 166be46, almost all of our built-in "Xenia Shading Language" shaders can now be compiled as MSL. The exception is the FidelityFX ones, as they require writing the FidelityFX platform definitions that currently exist only for GLSL and HLSL, and also wrapping the whole shader in a class storing references to the bindings as fields initialized in the constructor called via an entry point thunk, since Metal resource bindings, unlike GLSL/HLSL ones, are not in the global scope, but rather, they're entry point arguments that must be passed to callees explicitly if needed (or, references to them must be stored in some object that is also passed somehow, including via Note that because of our custom |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I wonder if the recent announcement by Apple in the WWDC'23 changes things with the Game Porting Tookit: https://developer.apple.com/videos/play/wwdc2023/10123/ Seems promising! |
In some context probably, we definitely can't test how Xenia would ran on a Mac as it requires AVX instruction set and Rosetta can't interpret those, tested it out a few days after WWDC and yeah, expected result.
|
|
Now I'm thinking about trying to find a way around this problem. One thing that comes to mind is rewrite the AVX code to use something more portable like a library. This library sounds promising: https://ermig1979.github.io/Simd/ |
|
Xenia actually emits AVX code during translation of PowerPC instructions at runtime. Implementing a non-AVX version would be very non-trivial and quite an overwhelming revisiting of all of our emitted assembly. |
|
For anyone coming here, as of macOS 15 Beta 1, Rosetta 2 doesn't expose any information about supporting either AVX or AVX2 which Xenia or RPCS3 check for, thats why it won't work for now, whatever their approach to this is, it's a mess now. |
|
I only seem to see AVX2 mentioned in relation to GPTK2 and not Rosetta generally. I should note though that I have implemented an ARM64 backend for Xenia that is just waiting to be merged at the moment, so the need for emulation through Rosetta may not be necessary. I have an M2 Mac Mini I could do Mac testing on, but I don't think there is any build-infrastructure in-place for Xenia to compile on Mac at the moment. The CPU-backend is ready to go though once that comes online. |
|
From someone I know who tested it, it's not exposed by the kernel yet, so you can't run macOS Edit: I have not verified this myself, as I have not installed the beta yet. |
AVX2 needs AVX1 to work, that's kinda obvious. What's funny some of AVX1 feature set work, tested in RPCS3 with LLVM CPU set to AVX1 CPU runs with slightly better perfs, but setting AVX2 CPU crashes. General rule seems to be some stuff will work unless it won't actually check for either AVX1 or 2 support. Yes, Apple mentions AVX2 in docs because end users already confuse it anyways. Thanks, Apple I guess 🎉 |
|
I forked Xenia and merged the arm64 backend PR into it, and came across several issues building on macOS:
Edit: |
|
It works on WINE / GPTK2 now: Native build would be way better of course :) |
Thats long way to go, even RPCS3 isn't native. As of Beta 2, Rosetta 2 was updated but still reports same feature set. Features: AESNI,CLMUL,CMOV,CMPXCHG8,CX16,FXSR,FXSROPT,LAHF,MMX,NX,OSXSAVE,POPCNT,RDTSCP,SSE,SSE2,SSE3,SSE4,SSE42,SSSE3,SYSCALL,SYSEE,X87,XSAVETheir feedback answers towards this issue are somewhat funny and concerning at once. |
|
Are you sure? You can compile rpcs3 native for aarch64 Linux, have not
tried for MacOS though yet...
Marcin Mitura ***@***.***> schrieb am Di., 25. Juni 2024,
21:49:
… Native build would be way better of course :)
Thats long way to go, even RPCS3 isn't native.
Ideal goal for now would be AVX exposure to pass the check.
As of Beta 2, Rosetta 2 was updated but still reports same feature set.
Features: AESNI,CLMUL,CMOV,CMPXCHG8,CX16,FXSR,FXSROPT,LAHF,MMX,NX,OSXSAVE,POPCNT,RDTSCP,SSE,SSE2,SSE3,SSE4,SSE42,SSSE3,SYSCALL,SYSEE,X87,XSAVE
Their feedback answers towards this issue are somewhat funny and
concerning at once.
—
Reply to this email directly, view it on GitHub
<#596 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAANGLBBRLVWVHLIX5V4MCLZJHCTRAVCNFSM6AAAAABJGV2NKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBZHA2DQMJXHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Yes, you can but it doesn't mean it will work just as good as x86_64 release, especially in macOS case. Linux at least have way better support than macOS does. See: RPCS3/rpcs3#15567 But that's getting offtopic a bit. |
|
As of macOS 15 Beta 3, thats the funniest shit I've ever seen: But to be fair, regardless of CPU-Z through Wine report and recently introduced AVX exposure variable, it's just can't detect it lol. Using Features: AESNI,CLMUL,CMOV,CMPXCHG8,CX16,FXSR,FXSROPT,LAHF,MMX,NX,OSXSAVE,POPCNT,RDTSCP,SSE,SSE2,SSE3,SSE4,SSE42,SSSE3,SYSCALL,SYSEE,X87,XSAVE |
anyone have this working in the GA release of macOS Sequoia? I had it working in beta a few weeks ago and it was pretty impressive to see it even running through so many layers of translation. One of the titles I own is just a simple XBLA puzzle game and it worked well enough to take the game on the go. I updated to macOS Sequoia and built xenia_canary from from source with the AVX check patched out and now it just crashes. I'm under the assumption that GA release of Rosetta 2 has the "experimental" AVX2 bits patched out. Anyone else confirm this or otherwise? |
You are fully aware patching the check is not a solution, it's just Apple fuckup that they fail to recognize or I have luck to lame employees jumping on the issue. Current AVX implementation still has issues even with their "promise".
I like how when I covered Mac app issue, they said ItS fOr WiNE oNlYy forgetting I've mentioned also running Windows exec (Xenia in question ofc) through Wine ffs. |
for xenia to run in gptk/wine on sequoia, you need an edited build with avx detection patched out, as macos does not advertise to the programs that avx is supported, even though it is supported. |
|
Well Apple claims they do but it's hard to speak to them through feedback when they treat you like an idiot and when you loose temper they just dont respond to your tickets at all lmfao. So yeah it works but implementation by either side is so shitty that it doesn't if that makes sense. |
and others
Is there a way to Compile for Mac?
The text was updated successfully, but these errors were encountered: