DirectX 12 Support on macOS
twitter.com
twitter.com
https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...
Apple did contribute to the Wine codebase and have their own translation layer.
Performance and compatibility seem to be much better than what Codeweavers showed which is expected given the translation appears to be DXIL to MSIL instead of DX to VK to MS.
The Mac gaming Reddit has a bunch of people posting results
https://reddit.com/r/macgaming/hot
And someone’s already made a tool to simplify running games
https://github.com/IsaacMarovitz/Whisky/releases/tag/pre-0.2...
This is also a triumph for open source imho because wine is now receiving patches for macOS directly, and it’s a symbiotic relationship that hopefully grows.
Things look very promising.
I wish. Unfortunately the MetalD3D is proprietary under a very restrictive license. The rest is just Wine code written by Codeweavers.
Obviously it would be nice if MetalD3D was also released under a better license, but it's hardly as though this omission is a big loss to the wine project.
The license to their translation layer(which is closed source) is very restrictive and basically only allows use for evaluation purposes.
The Windows EULA didn't allow people who built their own computer to buy the cheaper OEM version of Windows. They were supposed to pay full retail.
I would expect to see people care about this license agreement restriction just as much as they did when they built their own PC and installed the OEM version of Windows on it.
> Apple did not upstream anything to Wine here.
So what you're saying is that Apple didn't do anything useful for the Wine project and you're angry because after Apple did nothing, they failed to open source the nothing. Okay then. I don't follow you.
Can you explain this. Game Porting Toolkit code is LGPL the same as Wine.
https://www.reddit.com/r/macgaming/comments/142tomx/apples_g...
And the restrictive license part is this:
"you are granted a limited, non-exclusive, non-transferable, personal copyright license to (i) install, internally use, and test the Apple Software for the sole purpose of developing, testing, or evaluating video games for use on Apple-branded products"
That this exists is hilariously self-defeating. Linux gaming is becoming Proton-driven, so with this and VKD3D, we're potentially looking at Direct3D 12 as the most widely supported cross-platform API. Why write Vulkan or Metal when D3D runs everywhere now?
My understanding; the license won’t allow them to settle if a third party seeks patent licensing from them over shipped GPL code - they have to ensure everyone using any derivative of the upstreamed code is also covered by that patent license.
https://raw.githubusercontent.com/apple/homebrew-apple/main/...
:
url "https://media.codeweavers.com/pub/crossover/source/crossover-sources-22.1.1.tar.gz", using: TarballDownloadStrategy
The release precedes CrossOver's 23 release with DirectX 12 support though. (Though you'd think that many bits are already there in prior releases.)Edit: I poked around a little in the game porting toolkit and it seems different. They have a D3DMetal framework, whereas CrossOver's Direct3D 12 support goes through MoltenVK.
Wouldn't they have been better off just supporting Vulkan?
An obvious example would be OpenGL, which nobody has called a well-designed API.
But there's other misfires as well. OpenCL hasn't exactly set the world on fire compared to CUDA. OpenVG was a standard for accelerating 2D Graphics that was a little too late to matter. OpenXR? Well, at least Oculus is actually using it. WebGL? The W3C is working on replacing it with the (far superior) WebGPU. WebCL? Well, that was a JavaScript system for OpenCL, and that was as bad of an idea as it sounds.
And of course, most recent example: Vulkan. Almost everyone who has actually used Metal has commented on how it is much, much easier to hit the ground running than Vulkan, because Vulkan requires mountains of boilerplate. (It's also worth remembering that every iOS Developer builds for Metal, so it isn't like there isn't knowledge out there about how to use it - it's just among mobile game developers instead of the AAA developers).
Yes, Vulkan comes with more boilerplate. But who cares? Vulkan was meant to write your engine in, not something you call directly from client game code. It works extremely well and Khronos deeply cares about Vulkan and continuously improves it. Part of the verbosity also comes from the fact that Vulkan scales from small embedded SoCs to big gaming GPUs and everything inbetween, so the API has to cover a lot of potential hardware quirks. Viewing Vulkan as a kinda low level HAL helps explain a lot of the verbosity.
Anyways, long story short, I absolutely love working with Vulkan and after having been Vulkan programmer since basically day 1 of its existence, you can take it from my cold dead hands.
OpenGL wasn't designed by Khronos, rather it was designed by SGI and called GL. It was then given to Khronos and then maintained it.
OpenCL wasn't designed by Khronos either, rather it was designed by Apple and then given to Khronos to maintain. It was orphaned when Apple gave up on it, and not because of Kronos's leadership but rather Apple decided to go all in on Metal, their proprietary solution that did graphics and compute shaders.
Vulkan also wasn't fully designed by Khronos, rather it was based heavily on Molten from AMD, which was gifted to Khronos. It is much more widely used than Metal.
That said, benevolent dictators who are competent can out do committee decision making, but committee decision making is often better for an industry as a whole because it aligns different interest groups.
[0] https://www.khronos.org/news/permalink/apple_dell_google_and...
By default, pretty much every gaming platform has it's own proprietary graphics tech.
we've got Metal on Macs and iOS, DirectX on Windows and XBox, and Gnmx on Playstation.
I think they are keeping an evil eye on asahi linux. As soon as that becomes viable, they'll act to keep people on OSX. Their worst nightmare would be steam actively moving to support proton on mac and doing things outside the apple store. Asahi linux would be the pre-cursor to that happening.
Linux on the Desktop - Apple Silicon edition.
They clearly see the Mac a bit differently than they do the other iDevices.
That's a scenario Apple would want to avoid. Hence the announcement of a porting kit.
If you think that (even with a fully parity with say Ubuntu on Intel Asahi) people would move to Linux on their Mac on any number enough to even raise an eyebrow (much less worry) Apple, you are delluding yourself.
People buy Macs to run macOS. A very tiny minority buys Macs to run Linux on. A slightly larger (but still insignificant) minority will convert an old Mac laying around to Linux.
It's enough to get a project like Asahi support, not enough to make even a 1% dent on Apple's software/services ecosystem bottom line (the hardware side is the same, as those people are still buying a Mac anyway).
The D3D APIs are by far the most popular for PC games, so it makes a lot more sense to support D3D. Also, Vulkan on Mac is already supported "well enough" via MoltenVk.
FWIW, the Open Source community has had DXVK running >80% of the titles on Windows for years now. The real champion isn't even Apple here, it's Codeweavers for keeping Wine fresh on MacOS and Valve for pushing gaming on UNIX-likes to it's logical conclusion. Writing and maintaining Wine is a feat Apple is not legally well-poised to do - without the tireless toiling of Open Source contributors, this feature would not exist.
So welcome back to gaming, Mac users. Let's hope this isn't a stopgap offering and more of a jumping-off point for DirectX9 coverage and the like.
Previously: DirectX -> Proton/WINE -> Vulkan -> MoltenVK -> Metal (yuck)
Now: DirectX -> Apple GPT (groan at my pun, Game Porting Toolkit) -> Metal
You could call it Proton with a Metal backend and more developer tools?
It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.
This is a Developer tool to help developers figure out what it’s going to take to port their games to the Mac.
End-users don’t get to use it. You can’t bundle it with your game. The license forbids it.
It’s very interesting, and I’m sure the community will make the best use of it they can, but it isn’t designed to be the Mac Proton.
Also, whenever the Direct3D API changes, they would have to follow. That makes them dependent on Microsoft and means they’d always lag them.
Because of that, I don’t see them open this up.
By running them on a DX12 translation layer that they can't utilise? What would be the use case then?
Of course if Vulkan was a suppoted API on macOS, developers could just port to Vulkan on Windows and then implement the rest on macOS.
At least this was the messaging in their talk about this: first you had to work months on a port to see how well a game would work on Mac hardware, now you can immediately run it, investigate bottlenecks and see where a port would land performance-wise before putting in any of the work.
I wonder if they will make the D3DMetal usable from native code as well, I can imagine that would make porting much easier:
- First you run on Wine + D3DMetal to get idea if your game would run well enough on Apple hardware at all.
- Then you start building the game natively, still using D3DMetal, so that you don't have to immediately port the graphics stuff.
- Once you have a running game on top of D3DMetal, you start porting it over to Metal with their shader converters, etc.
Butthurt mac users that don't like to think their toy is worse somehow, obviously.
Another factor is that major GPU companies put efforts into rewriting some games' shaders to make them run better on their hardware. I doubt Apple is going to do that so you'll probably end up with games performing better on other platforms soon after release.
There's more to getting games to run smoothly on a platform than compatibility software. So far, the GPU has been lacking despite Apple's attempts to hype up gaming for mac. With the rate things are going, the year of gaming on Mac may be the same as the mythical year of the Linux desktop: inching ever closer but never really arriving.
Assuming this thing takes-off and suddenly the RGB LED-illuminated crowd switch to Apple hardware and macOS, then it's a very depressing thought because it means Apple will veritably make hundreds of millions (billions?) of dollars off Codeweaver's (and their extended community)'s work - and they'll get-away with it because their revenue can be classed as hardware sales, and not software licensing.
I honestly don't know how to feel about this.
I do feel a pang of smugness seeing the (post-iPhone) Apple having to stop pretending that copyleft doesn't exist[1] but also seeing them acknowledging that ecosystems other than their own do actually exist, but ultimately favourable smirks are in no way any kind of compensation to the unpaid effort put in by many of Wine-and-co's devs.
I suppose Apple could do the decent thing and offer to acqui-hire Codeweavers et al., but that's more akin to a heavenly afterlife for Codeweavers' people (i.e. after acquisition Codeweavers would necessarily die along with their mission (beyond Apple's own self-serving uses) which might be a bigger disservice to everyone involved, especially the community.
----------
Unrelated-but-related: is any of Wine or Codeweavers' code under GPLv3? If so, that's might be the undoing of Apple's locked-down bootloaders: supposing that iOS, iPadOS or visionOS/xrOS includes DX12 compat via GPLv3-derived code: would Apple be legally obligated to explicitly allow users to install their own firmware contrary to their user-hostile, regressive, and (imo) indefensible policies so far?
-----
[1]: Apple avoids the GPL, but so do all the large incumbents (though of course, like literally everyone, Apple is now fairly on-board with MIT/BSD licenses) - I do note that the KHTML-derived WebKit retains its GPL licensing, is a single, huge, exception, but I also note that Apple, internally, heavily firewalls-off their WebKit devs from anything else. (I've visited Apple's offices in-person and while the pizza place in the central cafeteria is nice, the fact that their SWEs can't casually walk down the hallway into another product team's office and exchange misc advice is just downright _weird_ to me, that's why I withdrew my only application to work there)
As a user... Tell me why I shouldn't just run games directly on Windows, the native platform?
If you’re fine with using Windows then knock yourself out! I just came from another thread where people were complaining bitterly about the nonsense and dark patterns Microsoft is pumping into Windows to monetize users to the hilt. Frankly, I’d rather just avoid all of that!
Because DXVK is cool, and in many cases better.
Windows isn't my primary operating system because gaming isn't the primary thing I use my computer for.
I code, and in a similar way doing software development on Mac and Windows appears to be "just run Linux in a VM and pretend to use the primary operating system".
Removing OS silos for gaming is amazing, Valve really opened the floodgates with Proton. Windows, Linux and now macOS all being able to run same games is just great.
Playing the same game on Linux, an OS that doesn't disrespect me as a user, is awesome!
That is not true at all. Ignoring Mac as a gamedev is one of the easiest decisions we've ever made at every studio I worked at. Even the studio where the boss used a Mac! The market share is minuscule and lacks even the Steamdeck and proton pushing linux support into Steam games.
That Apple saw fit to half-effort this tooling then lock it behind a license which prevents gamedevs shipping with it, and steam from packaging it, means Apple has yet again demonstrated their time tested poor support for games.
Lag time in port availability also probably factors in too. If you open Steam on a Mac you’re shown a bunch of brand new games without Mac ports… if you don’t dig a little deeper it gives one the impression that they don’t have many Mac games and isn’t worth bothering with.
Instead it sounds like you are reaching for excuses to ignore what you wish to be not-true. You clearly care a lot about gaming on Mac. Sadly Apple does not care. Hence how a rather decent US PC market share translates to trivial games market share.
When Apple starts caring they have the money to buy ports. There is no need for excuses.
If you're talking about Railgrade (from your bio), couldn't that simply be because your game only shows as supporting Windows? Why would a Mac user wishlist a game they can't play? Linux users have had Proton for a few years now and the discussed Mac toolkit was only announced a couple days ago.
If the Linux users were vastly out of line, I'd question them. Instead they are inline with the Steam survey. Anyway, the idea that Mac users are not big games is about as controversial as the color of the sky.
Regardless, I definitely didn't mean to imply that Mac users are big gamers. Most Macs are MacBooks and most people don't buy a laptop primarily for gaming. It'd be a secondary concern. There's also a chicken and egg situation in which Mac users may not be big gamers because there's not many games for Macs (not to mention that Steam runs terribly and is buggy on M-series Macs). Any Mac users that are big gamers probably have a console and/or PC (like myself) due to this situation, so any wishlisting is done on the device I play games on, despite the desire to be able to play on the go on my MacBook. Any Mac users that aren't big gamers may be due to having limited games. My wife who isn't a big gamer, but does like to play games occasionally, is relegated to using Bootcamp on her iMac.
Now I can run Linux as my daily driver, since I can run games properly.
I genuinely want to know the real answer, because this kind of behaviour confuses me. And every time I ask someone about it they don't answer, or give a non-answer.
If HN blocked comments with certain words, I'd understand.
If you genuinely find fuck an offensive word, and instead chose to use some other word instead, I would understand.
But this makes no sense. Please be so kind as to explain.
You hear an analogous effect used a lot in spoken speech (definitely in the UK, not sure about USA), for example, "ff-<beat>-in' thing". This stresses it in a way, similar to varying tone or volume, that would be missed in a flat reading.
There are many better ways of calling attention, or adding emphasis to profanity without having to resort to making it look less profane.
And in the specific case of the comment I replied to it does not look like they were particularly angry or frustrated enough to apply this technique of yours to just one word, while the rest of the sentence is fairly innocuous. And I further doubt that if any (neutral) literary analysis were to be applied to that comment, that people would think that stormking was so angry that they were actually trying to apply any kind of emphasis the profanity.
> There are many better ways of calling attention
Written expression is a form of art, not a formula with a correct answer.
Some developers noticed this when Valve released the Steam Deck and Proton. Some had Linux ports but they were slow and didn't work perfectly. They just removed those and let the SD run the windows version through Proton. Boom, Linux version :D
Having it as an option when I travel business would be great.
And I don't play every week anymore but I will play certain games.
It solves the itch without needing a ps5 or a PC.
Edit: More information here: https://www.digitaltrends.com/computing/apple-enabled-thousa...
Also it’s more special than Proton for Mac because Proton does DirectX to Vulkan (needing a second round for Vulkan to Metal through MoltenVK), this is DirectX to Metal.
Of course Apple has split off their graphics API so they had to do the translation work for Metal themselves, but playing DX12 games on Wine isn't all that special.
- Mainline D3D12 implementation on stock Wine;
- Proton (Which in theory should be just the "unstable" channel of the wine reference implementation plus some Gallium/VKDX/Valve specific stuff) plus a bunch of branches floating around (proton-ge, lutris custom builds, etc) ;
- Crossover (on the other side, this should lean on the safer side compared to reference wine, with just a bunch of explicitly whitelisted games);
- And now, the Game Porting Toolkit by Apple.
I wonder if there's some serendipity between those projects or we're gonna end up with some games running on some specific branch of Proton DX12, others stuck on mainline wine, and others for a reason or another working correctly just on Metal.
Apple has been doing their usual thing, with slowly moving pieces into place, but it's been pretty clear that they're ultimately going to go for a slice of that cake. Aside for mobile gaming, it's essentially an untapped market for them, given the footprint they now have with their devices. Also, they're going to want to shift the VR game development efforts to the Vision, in time for the release of the non-Pro version.
It'd be smart of them to partner, or at least cooperate with, Valve around this, but I'm not so sure about that one. Apple _might_ have enough hubris that they'd try to supplant Steam rather than work with it. This would be a mistake in my opinion.
Honestly feels like a fractal of hacks upon hacks. Makes something like Slack feel native.
I know people are passionate about it because their games are locked into the service but the UI is godawful.
Windows ... emulator? Does this mean we can now play old Windows EXE games? E.g. can I now run Fallout 2 and 3 like I did on an old Intel Mac with Crossover?
Can it also run Windows apps which don't use DirectX? I need some for work and have to use Parallels now.
Does it support Windows crypto APIs (certificates etc)?
Things like the crypto API should be implemented if you can find the reference for your specific API calls here: https://github.com/wine-mirror/wine/tree/master/dlls/crypt32
Apple's version of Wine is aimed at developers, though. It shouldn't take too long for someone to make an app or script to easily set up environments with the developer runtime, but I doubt they'll support it as well as Valve supports Proton. If your application of choice doesn't need any fancy graphics, there's a decent chance Wine/Crossover can already run it anyway, no need to mess with Apple's SDK.
With the M2 Max outputting 28fps at 1080p (screenshot linked), I wouldn't expect too much from the gaming performance of this thing, though.
I know Apple isn't exactly a company that's open to adopting other people's standard when they might as well develop their own, but the split from the other API standards was still a choice they made.
There you go: https://github.com/IsaacMarovitz/Whisky
Here is a bit more promising sample about the performance on M2 Max: https://www.reddit.com/r/macgaming/comments/1435ukq/cyberpun...
It's also possible to only simulate the entrypoints through Rosetta and then execute native aarch64 code from there. On Linux https://github.com/ptitSeb/box64 does exactly that, for example. However, with the performance Apple has been able to squeeze out of Rosetta, I'm not sure of that workaround is even necessary.
I _think_ you can run crossover with rosetta and still do this, that is basically what this is plus a DX12 -> Metal translation module
This isn't the DX12 emulator itself, right? It's just a patch to crossover which makes it use the emulator which is proprietary and bundled with the OS (or Xcode)?
The graphics bridge libraries need to be placed inside your Wine prefix in order to finalize your game evaluation environment. These instructions assume you have mounted the Game Porting Toolkit at /Volumes/Game Porting Toolkit-1.0. • Copy the Game Porting Toolkit library directory into Wine’s library directory.
ditto /Volumes/Game\ Porting\ Toolkit-1.0/lib/ `brew --prefix game-porting-toolkit`/lib/
They literally made a new Direct3D implementation on top of Metal.Platform support is of course an argument when choosing an engine.
The PC and (M1/2) Mac versions were out of sync for a few months, making multiplayer games between those impossible.
Worked perfectly with PC + Steam Deck though.
Hell, something as basic as shipping a working binary for a non-trivial executable on Linux is a bit of a sick joke. Let alone having to support several windowing systems, and a whole bunch of new platform specific bugs in sound systems, graphics drivers, desktop environments, controller APIs.
Mac and Linux have just never been worth the tiny market for large studios. Many games using Unity and Unreal, which can target MacOS and Linux, don't bother providing Linux and MacOS builds because the development and support burden is too high for the number of users they'd gain.
Remember that this isn't a toolkit aimed at users and hackers, it's a developer toolkit.
Don't let perfect be the enemy of good - things are only going to get better.
Also, game developers have been burned time and time again by Apple's inability to have a stable API + forced updates to the new crappy API, so no, they still won't port.
M series is great but once you’re on desktops it gets left in the dust by Nvidia for 3D and ML.
No, even when they shipped that support initially it barely worked and then support ended one OS release. Nvidia stopped shipping drivers so it hasn't been possible for around 6+ years now?
Looked into it extensively at the time and price and support wise I ended up having to build a PC to use Nvidia for 3D work (Octane Render).
> Also doesn't M2 have some sort of an accelerator built-in specifically for ML?
Yes, and it's good for a laptop but to put it in perspective M1 Max takes around 45-50 seconds to generate a Stable Diffusion image, 3090 takes around 5 seconds.
MacOS is a toy.