From a performance and technical perspective this is incredible. Well done!
It will never happen, but my dream is for the Asahi devs, Valve, and Apple to all get together to build out a cross-platform Proton to emulate and play games built for Windows on both x86 and ARM hardware running Linux.
A Steam Deck with the performance and power efficiency of an M-series ARM chip and the entire library of games that run on Proton is just...dreamy.
rowanG077 42 days ago [-]
I'm not sure if you know. But Alyssa, the person who basically wrote almost the entire userspace opengl and vulkan driver, works at valve.
dcchambers 42 days ago [-]
Wow! I wasn't aware, but that actually gives me a ton of confidence that Valve isn't ignoring ARM with all of their Linux + Proton work.
Her output is incredible.
adastra22 41 days ago [-]
I hope they don’t ignore macOS. They could port proton to run on Metal + Rosetta and then Steam would support all running windows titles on macOS and Linux.
I recognize it’s a hell of an ask, but I think Alyssa could pull it off.
pmarreck 41 days ago [-]
I'm a huge macOS fan but even I have to admit that gaming deserves to have a home on an open-source OS controlled by no one (which would be Linux in this case) and that Steam devoting effort to bring first-class gaming from Windows to macOS is like working to escape from the frying pan into the fire.
satvikpendem 40 days ago [-]
I use whisky which is WINE underneath to play games on macOS.
I see cats writing software _with hardly any documentation_ like this and my brain melts. Power level strictly monotonic, possibly exponential, and very very large. Bravissima!
psd1 41 days ago [-]
I hope that she was working on Asahi full time at valve, because if she did all that while also holding down a day job then I might as well be soylent green.
A lot of stuff like this shows up, they also have a fork of waydroid and box64. I think a lot of them are projects and a lot of them are just devs with a lot of agency who share the dream
scheeseman486 41 days ago [-]
Steam Deck was made possible by their ongoing efforts to enable the play of most of their games catalog on any hardware platform that is computationally capable of running them, regardless of OS or architecture.
The end game for Valve isn't Steam Deck 2 or 3 (which is statistically impossible for Valve to produce), but for Steam to be on everything.
pjmlp 41 days ago [-]
Steam Deck was made possible by the plethora of the Windows games developer market and Proton.
Most of the studios that own those games, and target POSIX like OSes on mobile phones and game consoles, are yet to bother with GNU/Linux versions for SteamOS.
scheeseman486 41 days ago [-]
Wine and DXVK are already running on Android and they play Windows games with the rendering and computational complexity of Fallout 4 at playable framerates on many of the latest smartphone SoCs. It's still WIP, but it's already gone beyond proof of concept, people are using them. Valve don't need the developers to be on-board in order to run their games on anything else, that's why Proton exists.
What Valve want is the dissolution between platform/architecture and store. By my eye, it's the driving force of their efforts, more so than them selling hardware or being the open source good guys. Not to undervalue their work in helping make Linux a first class citizen for gaming, but the core of their business model is getting people to engage with their store, full stop, and being able to sell their games on Android (and elsewhere) would massively extend their reach.
This may go both ways too, there's also been indications that Valve have been tinkering with Waydroid, meaning Steam could also become a store for Android-native games.
pjmlp 41 days ago [-]
It looks more like how to avoid paying Windows licenses for the SteamDeck to me.
wtetzner 41 days ago [-]
I'd guess SteamOS is more about control than licensing costs.
I don't think Valve wants to be at the mercy of Microsoft and their policy & technical decisions.
kbolino 41 days ago [-]
That's a small part of it, I think. They've almost certainly spent a lot more on pouring time and effort into Linux than they ever would have saved on license fees. It seems like Valve doesn't want to be beholden to Microsoft in any way. They support Windows because that's where the users and the games are, but they don't want Microsoft to be able to rug-pull them either.
pjmlp 41 days ago [-]
Except that they are, to the extent they depend on Microsoft technologies for the games that run on Proton.
kbolino 41 days ago [-]
As far as I am aware, neither Valve nor the independent Wine/Proton developers are bound by any licensing agreements with Microsoft. They are clean-room implementing the same technologies, but they are not beholden to Microsoft in any legal way. Of course, drastic changes in laws or policy regimes could alter this dynamic, but those are out-of-context risks.
In order for Microsoft to rug-pull the technology (which is quite different from rug-pulling the business model), they'd have to break compatibility on Windows itself. Video games remain a major reason for home users to run Windows. Making ABI-breaking changes to Win32 or DirectX is just not very likely to happen. And if it did happen, it would be a boon to Valve and not a harm.
The biggest risk (and this would be a classic Microsoft move, to be fair) I can foresee is aggressive API changes that make it hard for Valve/Wine/Proton to keep up but also make it hard for game developers not to. I'm not exactly sure what this would look like, and a lot of the core technologies are pretty stable by now, but it's a possibility. It's not, however, going to harm anything that already exists.
homebrewer 41 days ago [-]
They can restrict .NET and the C++ stdlibs so that you can only run them under Windows (through a license change or by introducing a code check), but if they hadn't done that in Ballmer days, I don't think they will now.
rowanG077 40 days ago [-]
Not they aren't dependent on Ms tech. Wine is not by ms.
p_l 41 days ago [-]
I don't remember how officially it was stated, but original push by Valve for steam on Linux with Proton was to remove their dependency on Microsoft - a hedge against possible future ecosystem-impacting decisions in Redmond.
Making SteamDeck use windows wouldn't impact prices much, Microsoft is really friendly for putting windows by OEMs. Could even run modified to act like current steam deck.
Instead, SteamDeck is there to drive up testing on Proton or straight forward porting to Linux, which just availability on Linux and the previous steam machine didn't drive up
sandworm101 41 days ago [-]
Close, but the root is more nuanced. Once upon a time, Microsoft was talking about regulating "apps" on windows like Apple does for the iPhone. Valve saw the writing on the wall: a potential ban on violent or otherwise adult-themed games. So Valve started the steambox project. Get the games running on linux/WINE and they could tell Microsoft to push off. Years later, we have the steamdeck as a revolutionary product and linux is the go-to OS for portable gaming.
pjmlp 41 days ago [-]
Running Windows games on top, which will work until it doesn't.
michaelmrose 41 days ago [-]
What trouble do you foresee?
johnfernow 41 days ago [-]
What do you foresee not working in the future?
If future versions of Proton break compatibility with older Windows apps, you can use different old versions of Proton for individual games. Steam makes this very easy on Linux, but rarely is it necessary.
I don't foresee many Linux distros breaking compatibility with Wine, which is good, as some devs argue Win32 is the only stable ABI on Linux. [1]
I don't foresee legal issues either, as Wine has been around for 31 years, and its corporate sponsors have included Google in the past. I've seen no indication that the project is on shaky legal grounds.
Microsoft could always create a new API that Wine doesn't yet support, but good luck getting developers to use it -- they've tried many times, but not much has stuck, and most devs just stick with Win32. [2]
I mean practice has shown it's not a problem. What else is there?
ikety 41 days ago [-]
Linux/Unix has been used as a base overwhelmingly in pretty much every new consumer OS for decades. Not to mention Microsoft certainly cuts deals with manufacturers when it comes to windows on portable devices (I think at one point they offered free licenses on devices with screen sizes under 8 inches).
The steam deck is 100% usable without leaving 'game mode' even a single time. Something that is genuinely impossible using Windows as a base. That's the important part
scheeseman486 40 days ago [-]
The amount of money Valve has pumped into Linux would have far exceeded the money they saved through licensing Windows. Like probably by an order of magnitude or more. For someone as smart as you seem to be, your points don't make a whole lot of sense.
talldayo 41 days ago [-]
[flagged]
sandworm101 41 days ago [-]
I am a strong linux supporter and I too do not like what proton is doing to games. A few years ago there were many significant games coming out with native linux capacity (MineCraft, KSP, Factorio). Then proton dropped. Now, rather than support linux natively, even the most pro-linux developers are just expecting that their windows version will run under proton. And those who are running games under proton are essentially cut-off from customer support. I've had a few games where a patch suddenly stopped them working under proton. I have no recourse in such situations. That is not a good trend.
ikety 41 days ago [-]
Genuinely what is the practical difference in this for 99% of users? They just want to play x game. Proton performance is pretty great, what else would be a problem for those people?
Also when it comes to breaking proton support (Which does happen) Valve + GloriousEggroll give you access to plenty of older and special versions. Surely that's better than rolling back entire software?
My game doesn't work ->
I go to protonDB ->
Users saying use X Proton Version or Y ProtonGE version ->
I switch the layer used in steam
Hard to imagine a simpler process than that
talldayo 41 days ago [-]
Linux is not a stable runtime in the first place. Unless you are isolating, redistributing and sandboxing most of the libraries used to run your game, it's almost guaranteed to break when the dependencies are updated. Windows apps don't have that problem, natively or when run through emulation.
homebrewer 41 days ago [-]
Just ignore the guy, it's essentially the reverse of "I run Arch BTW". Not just about Valve or Proton, but about pretty much every FOSS technology that's celebrated here.
pjmlp 41 days ago [-]
Because people love to celebrate Proton as if it was doing anything for GNU/Linux games, when in reality is another OS/2 take on Windows.
talldayo 41 days ago [-]
It doesn't have to do anything for GNU/Linux games, that's been an option for years and it's a ghost town a-la Metal-native games. Valve (and the community) are doing the right thing by ignoring the Apple strategy of enforcing distribution terms they will abandon within the decade. Developers that want to program for Linux still can. It's just as stupid as it was when the first Steam Machine rolled out.
By supporting Proton, they are guaranteeing that modern and retro Windows games will be playable on Linux far into the future. Trying to get the next Call of Duty to support Linux natively is, quite literally, a waste of everyone's time that could possibly be involved in the process. I cannot see a single salient reason why Linux users would want developers to release a proprietary, undersupported and easily broken native build when translation can be updated and modified to support practically any runtime.
sweeter 41 days ago [-]
Yea. You either have to pump a ton of money into it like Apple tries to do to get devs to target your OS, or you can take matters into your own hands and do the unthinkable with Wine and Proton. Its unironically a silver bullet solution. Otherwise we'd all be waiting for years to make 1/1000th the progress
johnfernow 41 days ago [-]
We don't have to imagine what Linux gaming would be like without Proton.
- CD Projekt Red: released Witcher 2 on Linux, didn't for Witcher 3.
- iD Software: released Doom 3 on Linux, didn't for Doom (2016) or Doom Eternal.
- Epic Games: released Unreal Tournament 2004 on Linux, but didn't for Unreal Tournament 3 or Fortnite. (A Linux port was being worked on for UT3, but it ended up getting cancelled.)
- Larian Studios: released Linux version of Divinity: Original Sin, didn't for Divinity: Original Sin 2 or Baldur's Gate 3
Many studios over the years have made native Linux versions, and many studios stopped because the cost of porting exceeded the revenue it generated. Proton didn't exist when Unreal Tournament 3, Witcher 3, Doom (2016), or Divinity: Original Sin 2 released, so Proton wasn't the reason those studios stopped developing Linux titles -- they stopped because it made no financial sense to continue to make them.
Now, with Proton, 79% of the top 1000 games on Steam are gold or platinum rated on ProtonDB. If you're fine with minor issues, 88% are silver rated or better. For the Steam Deck in particular, there are 5,500 verified games, and 16,526 verified or playable games. So I'd argue Proton is doing quite a lot for people gaming on GNU/Linux machines, since they now have access to a solid majority of the top 1000 games on Steam, both on a Linux desktop and on a handheld.
michaelmrose 41 days ago [-]
The practical implication is that one can click one button and buy install and play thousands of games on Linux. Only MS stockholders are liable to care about the implications for Windows.
scheeseman486 40 days ago [-]
OS/2's Windows compatibility was borne in the midst of Windows' rapid ascension, of rapid progress and change in the home PC industry.
We aren't in the 90s anymore. Win32 has stalled, Microsoft has a regulatory gun to their head and Wine's compatibility (at least in the domain of games) is extremely good, good enough to allow for a commercial product to be a success while being entirely reliant on it. In what way is any of this comparable to what happened with OS/2 outside of "it runs Windows applications"?
41 days ago [-]
freedomben 41 days ago [-]
You are right that many developers don't care and haven't bothered with Linux, but one reason for optimism is that this seems to be changing. Just looking through the list of native Linux games today compared to what it was like a year or 2 years ago, there are a lot more options. I was looking through the list of Linux games on Gog, and it is likewise in a much better position than it was prior. I think there is much reason for optimism!!
grahamj 41 days ago [-]
“There is now sufficient reason for greater optimism”
- Automated Personnel Unit 3947
lucasban 41 days ago [-]
What do you mean Steam Deck 2 or 3 would be impossible?
vundercind 41 days ago [-]
Steamdeck 3 being statistically impossible is a joke about Valve having an aversion to releasing a #3 of anything.
Half life 1, 2… hm.
Ok we’ll make three HL2 episodes to follow that up.
Ep I. Ep II. Uhhhh… and let’s stop there, just like forever I guess.
Portal 1. Portal 2.
Left4dead. L4D2.
Team Fortress. TF2.
Counterstrike. CS2. Oh shit we’re releasing a third one, we might have to use the number three finally, oh no… I’ve got it: CS:Go!
jakogut 41 days ago [-]
Also, the successor to CS:Go is...Counter-Strike 2.
vundercind 41 days ago [-]
Oh damn I got the order on those mixed up. Was probably thinking of CS Source.
Regardless, point stands: they hate the number 3.
echoangle 41 days ago [-]
They’re probably doing it on purpose as a joke at this point.
jakogut 41 days ago [-]
It would have to be, CS2 is the fourth major installment in the Counter-Strike franchise.
Then again, all kinds of companies take liberties with naming including numbers. Look at Windows 7 (12th major release), Windows 10 (successor to Windows 8), the game Battlefield 2 (third in the series), Battlefield 3 (three games after BF2), Battlefield 1 (after the release of BF4), etc.
ohmahjong 41 days ago [-]
It is a joke about Valve only rarely making the third installment in any of their series (e.g. Half Life 3 not existing)
Edit: specifically including "3" in the title - the actual number of games tends to be higher but with different names.
41 days ago [-]
reassembled 41 days ago [-]
Everything except Windows 7 and XP that is.
jchw 41 days ago [-]
I believe Valve dropped official Windows 7 support in Steam because Chromium did and they weren't going to fork it.
I empathize if you don't like any version of Windows newer than 7 or XP, but it's time to let the dream of running them forever go. It's not weird when software doesn't support the 2009 version of an operating system anymore in 2024. If they never dropped support, it would be difficult to take advantage of improvements that occurred in the last 10 years, because we'd forever be stuck in baggage.
Of course when it's feasible everybody loves software that really never does drop support, like 7-zip, which I think happily still works on Win9x without KernelEx... but I'd rather 7-zip stopped having serious security issues than continued to work on old Windows versions.
kbolino 41 days ago [-]
Windows 7 was great and I'd love to go back. If I really had my druthers, Windows 2000 was peak and XP was just a vulgarized version of 2000.
However, it is Microsoft more than anyone else that has decided to stop supporting those operating systems. Windows XP does not have support for any modern version of TLS (only TLS 1.0). There's no good way to support a browser-based app like Steam on a platform that cannot natively provide a secure connection to a modern web server.
There is not such a hard reason to drop Windows 7 support (again, except that Microsoft no longer supports it) but there are security-relevant APIs that are only available starting in Windows 10 which means special patches would have to be maintained just for Steam on Windows 7 to continue working securely.
dcchambers 42 days ago [-]
That's awesome news!
WD-42 41 days ago [-]
Apple is going to do the same thing they did with BSD, WebKit, etc. They will wait until proton is mature enough, fork it, then release it as their own. Why put in the effort this early on?
Which is exactly what I described. Looks like they took crossover/wine and added some custom patches. What are the chances they upstream anything? Probably 0.
tomnipotent 41 days ago [-]
Except it wasn't "taken", but licensed from CodeWeavers in a commercial partnership. This implies that they're contributing cash, not code.
WD-42 41 days ago [-]
Not sure what agreement they have there, but at the end of the day it’s Wine which has decades of open source development behind it at this point. Plus a bunch of other libraries (gstreamer being a notable inclusion) that are all FOSS. This still fits the pattern of Apple profiting off of OSS projects while contributing back as little as they can get away with.
tomnipotent 40 days ago [-]
A non-trivial number of contributions to Wine come from CodeWeavers (30%+ of all commits), which in turn is funded by its work on Crossover, Proton, and commercial agreements with other businesses. Wine would not be the project it is today without the contributions of CodeWeavers. Contributing cash to the companies contributing code is a perfectly adequete form of giving back.
CodeWeavers released an annoucement when Gaming Portal Toolkit was announced.
The announcement says practically nothing except “we did not work with Apple on this project.” And then a bunch of comments about the license Apple gave their version of the source code.
You sure there was any kind of commercial agreement? Doesn’t look like it.
WD-42 39 days ago [-]
In fact, reading into it more - they simply say "apple used our source code" this sounds almost explicitly like they are not paying, at all.
On top of that, Apple's DX to Metal code is not re-distributable. So yes, this sounds like more of the same from Apple.
WWLink 41 days ago [-]
I think it's still hilarious and crazy that safari/chrome/webkit/blink exploded out of the cute little KHMTL browser called Konqueror in KDE from back in the day.
And the root of the whole browser wars thing was microsoft making an absolute dog of a browser for Mac OS X when it came out and then refusing to support it. lmao.
pjerem 41 days ago [-]
Haaa Konqueror. It was THE shit back in the day. I loved this software. It really was at the core of the KDE experience. Too bad it disappeared, I miss it. (well it’s not technically dead but it’s not moving either)
pxc 41 days ago [-]
I came here to say this! Konqueror may have served a small community but it was excellent.
It was the file manager as well as the browser and it was incredibly capable. By far the most advanced GUI file manager of its time. And a pretty fast and pleasant browser, although the compatibility was hit and miss. (Those were Flash and IE-dominated days as I recall them.)
A lot of what I loved about Konqueror is captured in Dolphin. I don't think I need my web browser to be a file manager... maybe that concept was just a 90s fever dream. But I miss Rekonq. Maybe I should revisit Konqueror.
kombine 41 days ago [-]
Yes and I believe Dolphin is the best conventional file manager on the market - superior to the Windows Explorer and the file browser in in Mac OS.
pxc 40 days ago [-]
I miss Dolphin badly whenever I'm on non-free operating systems, even though I generally enjoy file management via the terminal as a fallback. In Plasma, I'm much more likely to do a bit of GUI file management than under any other circumstances.
'Default' KDE apps are often so well thought-out and complete that I never feel the need to deviate from them, and it's not unusual for me to install them on other operating systems when possible. I feel this way about Dolphin, Okular, Ark, Kate, Gwenview, Klipper, and Konsole/Yakuake, too (even though there are several great new terminal emulators out nowadays). And KWin! God, KWin's configurability is so good and it has some really killer compositor effects for productivity that are still unmatched.
aryonoco 41 days ago [-]
IE 5.5 for OS X was by far the most standard compliant browser of its time. It supported more CSS than either NN 4.x or IE 5 for Windows. Nothing came to surpass it until Mozilla 1.0 and even then it wasn't a slam dunk.
vitaflo 41 days ago [-]
Was gonna say IE5 on OS X was the opposite of “a dog of a browser”. It was the gold standard against which every other browser was compared because it was by far the most standards compliant browser of its day.
Also a quick correction, there was no IE5.5 for OSX. That was for Windows and used a diff rendering engine.
pmarreck 41 days ago [-]
Yep. I remember those days.
I also remember Safari on Windows, which was convenient for many reasons.
pachorizons 41 days ago [-]
Usually I would be as optimistic as you are about this, because that would be the dream (although it would be nicer for them to contribute to the project.) However, given Proton's primary use case is gaming, such an effort will almost certainly be kneecapped by Apple's historic half-hearted commitment to anything other than microtransaction-powered mobile games.
pmarreck 41 days ago [-]
Apple literally already has released a game porting toolkit which is basically Proton (see sibling reply)
0 chance they upstream anything. So in a way they are already benefitting from valves work.
simonh 41 days ago [-]
They won’t do anything to undermine Metal.
WD-42 41 days ago [-]
No but it looks like they’ll add Metal support to Wine, do the bare minimum to comply with the license and release it as “Apple game toolkit”. Textbook.
bmicraft 41 days ago [-]
An ARM CPU only emulating x86 isn't going to be more efficient than straight x86. ARM is barely more efficient as it is at those performance levels.
The real reason Apple is ahead is because they're paying for more expensive more advanced nodes for their CPUs. I you compare CPUs on similar node sizes, you'll see that AMD and Intel are basically caught up architecturally in perf/W metrics.
aurareturn 41 days ago [-]
This is definitely not true. M3 is 2x - 3x more efficient than Lunar Lake on the same N3B node.
adgjlsfhk1 41 days ago [-]
I don't think that's true. M3 has much better idle/near-idle power draw, but actual performance per watt when doing things is pretty close.
aurareturn 41 days ago [-]
No, it’s the other way around. Intel has generally caught up in idle power draw but is still severely behind in performance per watt.
The last I checked, there low wattage AMD and high wattage Apple had similar performance and wattage, so AMD was the right choice for raw performance, and Apple won for portable devices.
Intel was losing badly to one or the other at all TDPs. I don’t get the impression that’s changed much. (Even if it has, I can’t remember the last time I encountered a non-xeon intel machine with working hardware and drivers (for any OS, and I tried Windows, Linux and macs).
aurareturn 41 days ago [-]
AMD does not win over Apple for raw portal performance. AMD does give you a lot of MT performance for a decent price. You have to buy an M3 Pro to match an AMD HX 370. However, you’re sacrificing battery life, quietness, portability, and ST performance with AMD.
Brybry 41 days ago [-]
Remember that the latest Intel chips are a TSMC process node now, that's a pretty big change.
high_na_euv 41 days ago [-]
Have you seen Lunars iGPU?
aurareturn 41 days ago [-]
Yes, M3 is still 2-3x more efficient than Lunar Lake’s GPU as long as it’s not games that were more optimized for x86 and or DirectX. For example, M3 generally wins in compute with a lot less power needed.
high_na_euv 40 days ago [-]
Src?
adastra22 41 days ago [-]
There is no theoretical reason that is the case. These systems would be transpiling, not interpreting.
johnnyanmac 41 days ago [-]
that's ideally what Vulkan was for. Build for one common open source standard, and then Apple/Microsoft/Google/Linux can all build an API to support that.
But I guess there was never a time when an open graphics standard stood as the leader. Maybe during a brief stint in the Windows Vista era at best.
jorvi 41 days ago [-]
During the Unreal Tournament 99 / Quake 3 era a lot of games ran a lot better on Nvidia with OpenGL rather than DirectX.
shmerl 41 days ago [-]
You don't need Apple for that.
gchamonlive 41 days ago [-]
It's more likely it'll be Qualcomm instead of apple and eventually an arm based steam deck. These chips just make a lot of sense for handheld devices.
KeplerBoy 41 days ago [-]
Are the chips really fundamentally better than their AMD and Intel counterparts made on the same node?
Sure it's a great design, but I believe x86-64 will catch up once again now with everyone using TSMC.
psd1 41 days ago [-]
Arm has had a performance-to-power edge over x86 since inception.
AIUI, if you want the most flops per die, you'll buy x86 - probably the 128-core Xeon for enterprise money. But that's not what's best for hand-held gaming.
AAA titles are typically GPU-bound anyway. More CPU flops may not offer much benefit.
talldayo 41 days ago [-]
> AAA titles are typically GPU-bound anyway. More CPU flops may not offer much benefit.
Yes, but actually no. The Steam Deck is playing at extremely low resolutions. Rendering at 720p and 30fps is (on paper) 8x less demanding on the GPU than rendering a native 1440p60 experience. You can fully get by without having a powerful dGPU, which is why the Steam Deck is really able to play so many titles on a weak iGPU.
The problem is translation. Cyberpunk 2077 runs fine on a 25 watt mobile chip that uses x86, which is why the Deck even costs less than $1000 in the first place. If you try to put a mobile ARM CPU in that same position and wattage, it's not going to translate game code fast enough unless you have custom silicon speeding it up. There's really no reason for Valve to charge extra for a custom ARM design when COTS x86 chips like AMD's would outperform it.
For x86 PC games (which pretty much all games are, today), ARM is at a substantial disadvantage, period. The IPC and efficiency advantages are entirely lost when you have to spend extra CPU cycles emulating AVX with NEON constantly. If there were ARM-native games on Windows then things might be different, but for today's landscape I just don't see how ISA translation is better than native.
gchamonlive 38 days ago [-]
Yes, there would have to be a push in the industry to port games to ARM, otherwise the gains in architecture will indeed be lost in instruction translation
alexr243 41 days ago [-]
You can play windows game with this release in Asahi Linux! So it is possible now
tonyhart7 41 days ago [-]
or you know, just release a game on native linux build
pmarreck 40 days ago [-]
The reason why this isn't more prevalent is twofold
1) everything standardized, like it or not (note: I do not), on the Windows API, and it has remained relatively stable, which is important because
2) Linux-native games I've had, have become un-executable over time without semi-regular maintenance, and Windows games running on whatever version of Proton they best work with do not have that drawback
log_e 41 days ago [-]
If you want it to happen, ask them for it every day. You are their constituent.
Wowfunhappy 42 days ago [-]
> Tessellation enables games like The Witcher 3 to generate geometry. The M1 has hardware tessellation, but it is too limited for DirectX, Vulkan, or OpenGL. We must instead tessellate with arcane compute shaders
> Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute.
Is this potentially a part of why Apple doesn't want to support Vulkan themselves? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
(I realize performance is still relatively fast in practice, which is awesome!)
VHRanger 42 days ago [-]
> Is this potentially a part of why Apple doesn't want to support Vulkan? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
Yes, it's a big reason.
I tried to port the yuzu switch emulator to macos a few years ago, and you end up having to write compute shaders that emulate the geometry shaders to make that work.
Even fairly modern games like Mario Odyssey use geometry shaders.
Needless to say, I was not enough of a wizard to make this happen!
miohtama 41 days ago [-]
Why Apple does not just implement it? They have more resources than anyone in the world. Patents?
ribit 41 days ago [-]
Are you talking about Vulkan or about geometry shaders? The later is simple: because geometry shaders are a badly designed feature that sucks on modern GPUs. Apple has designed Metal to only support things that are actually fast. Their solution for geometry generation is mesh shaders, which is a modern and scalable feature that actually works.
If you are talking about Vulkan, that is much more complicated. My guess is that they want to maintain their independence as hardware and software innovator. Hard to do that if you are locked into a design by committee API. Apple has had some bad experience with these things in the past (e.g. they donated OpenCL to Kronos only to see it sabotaged by Nvidia). Also, Apple wanted a lean and easy to learn GPU API for their platform, and Vulkan is neither.
While their stance can be annoying to both developers and users, I think it can be understood at some level. My feelings about Vulkan are mixed at best. I don't think it is a very good API, and I think it makes too many unnessesary compromises. Compare for example the VK_EXT_descriptor_buffer and Apple's argument buffers. Vulkan's approach is extremely convoluted — you are required to query descriptor sizes at runtime and perform manual offset computation. Apple's implementation is just 64-bit handles/pointers and memcpy, extremely lean and immediately understandable to anyone with basic C experience. I understand that Vulkan needs to support different types of hardware where these details can differ. However, I do not understand why they have to penalize developer experience in order to support some crazy hardware with 256-byte data descriptors.
MBCook 41 days ago [-]
I’m not a game programmer, so I just sort of watch all this with a slightly interested eye.
I honestly wonder how much the rallying around Vulkan is just that it is a) newer than OpenGL and b) not DirectX.
I understand it’s good to have a graphics API that isn’t owned by one company and is cross platform. But I get the impression that that’s kind of Vulkan‘s main strong suit. That technically there’s a lot of stuff people aren’t thrilled with, but it has points A and B above so that makes it their preference.
(This is only in regard to how it’s talked about, I’m not suggesting people stop using it or switch off it to thing)
shmerl 41 days ago [-]
Nothing stops them from providing their own API and Vulkan both. So your arguments only make sense for why they might want other API but they don't make sense on the part reasons for completely denying Vulkan support alongside it. There is no good reason for that and the apparent reason is lock-in.
johnnyanmac 41 days ago [-]
Geometry shaders have almost always sucked in all fairness. I'm surprised a game newer than 2015 bothered with them. It's been pretty common knowledge that geometry shaders really only work better on Intel hardware (and I'm not sure how long that lasted).
Tessellation falling short is just classic Apple, though. Shows how much they prioritize games in their decision making, despite every other year deciding they need a AAA game to showcase their hardware.
(apologies for the crude answer. I would genuinely be interested in a technical perspective defending the decision. My only conclusion is that the kind of software their customers need, like art or editing, does not need that much tessellation).
dagmx 41 days ago [-]
Geometry shaders have long been disfavored by all ISVs , not just Apple. It’s just most include the software path.
If you’re using geometry shaders, you’re almost always going to get better performance with compute shaders and indirect draws or mesh shaders.
A lot of hardware vendors will handle them in software which tanks performance. Metal decided to do away with them rather than carry the baggage of something that all vendors agree is bad.
It takes up valuable die space for very little benefit.
Wowfunhappy 41 days ago [-]
In hardware? I would assume because it takes up space on the die, right? It's not free.
kelnos 41 days ago [-]
Because they don't care. They've decided that Metal is The One True Way to write 3D-accelerated apps on macOS, so they only implement the things in hardware that Metal requires.
wtallis 41 days ago [-]
There are definitely some features omitted from Apple's GPU, but fairly early in the reverse engineering process, Alyssa Rosenzweig provided several examples of hardware features present in Apple's GPU that are not exposed by Metal: https://rosenzweig.io/blog/asahi-gpu-part-4.html
Wowfunhappy 41 days ago [-]
Maybe, but we got here because I asked "is it possible that Apple doesn't want to support Vulkan (in software) because they don't want to support the features it needs (in hardware)."
If the reason they don't support it in hardware is because they don't want to support it in software, then the logic gets a bit circular.
I'm interested in which came first, or if it's a little of both.
p_l 41 days ago [-]
Vulkan very much is designed to give flexibility to hardware vendors. Where abstractions do paper over differences it's generally where it makes the abstraction cheap in runtime but you might take more code vs. less code but requiring a feature that would be otherwise optional (for example some of the complex pipeline manipulation Vs bindless)
achandlerwhite 41 days ago [-]
Perhaps, but also geometry shaders are generally losing popularity and on their way out. Per google ai search result (for what it is worth):
Geometry shaders are generally considered less necessary in modern graphics pipelines due to the rise of more flexible and efficient alternatives like mesh shaders which can perform similar geometry manipulation tasks with often better performance and more streamlined workflows
fl0id 41 days ago [-]
Because they like to be different tm
ronsor 41 days ago [-]
Why couldn't you just use MoltenVK?
slimsag 41 days ago [-]
MoltenVK doesn't support geometry shaders for ~3 years now[0]
Metal 3 (in 2022) added mesh shaders, which can be used to emulate geometry shaders.
We (CodeWeavers) are doing this in (a fork of) MoltenVK, and Apple’s D3DMetal is as well.
achandlerwhite 41 days ago [-]
Hi, is there a plan to submit these changes back up to MoltenVK?
mrpippy 41 days ago [-]
We would still like the changes to be upstream but they may need more polish, and it spawned a conversation about the division of responsibilities between SPIRV-Cross and MoltenVK:
Apple not supporting Vulkan is a business decision. They wanted a lean and easy to learn API that they can quickly iterate upon, and they want you to optimize for their hardware. Vulkan does not cater to either of these goals.
Interestingly, Apple was on the list of the initial Vulkan backers — but they pulled out at some point before the first version was released. I suppose they saw the API moving in the direction they were not interested in. So far, their strategy has been a mixed bag. They failed to attract substantial developer interest, at the same time they delivered what I consider to be the best general-purpose GPU API around.
Regarding programmable tessellation, Apple's approach is mesh shaders. As far as I am aware, they are the only platform that offers standard mesh shader functionality across all devices.
mandarax8 42 days ago [-]
Geometry shaders are not part of base Vulkan. They're an extension.
ornitorrincos 42 days ago [-]
they are not an extension, they are part of core 1.0 vulkan.
Although its true that they are an optional feature (as is tessellation).
shmerl 41 days ago [-]
That might be an excuse, but that's hardly a reason. They are simply extreme lock-in proponents and don't want to support cross platform graphics API. That's the real reason.
wtetzner 41 days ago [-]
> They are simply extreme lock-in proponents and don't want to support cross platform graphics API.
Which seems like an ineffective move when you have no market share.
shmerl 41 days ago [-]
They don't seem to care. I'm sure that will bite them in the long term, but for now they are very intent on complete NIH and lock-in anywhere they can push it.
gigatexal 41 days ago [-]
I’m just blown away at all the work they’re able to do with a platform that they basically reverse engineered. I’m glad to be contributing to their efforts. I’m also waiting for when M3 support comes! Such a cool group of engineers and hackers. I love it.
ZiiS 41 days ago [-]
For people like me who have been using Ashai for a while but are not Fedora natives; TIL `sudo dnf system-upgrade download --releasever=40; sudo dnf system-upgrade reboot` is necessary first as the normal upgrades left me on 39.
spease 42 days ago [-]
This is super cool.
So, wait, does this mean that gaming is better on Linux, on a Mac?
hu3 42 days ago [-]
I've been gaming on Linux since Warcraft 3 days.
Wine is wonderful and with Valve's help it only got better.
But why would gaming on a mac be better? Maybe one day, but for now:
FTA: "While many games are playable, newer AAA titles don’t hit 60fps yet."
Wowfunhappy 42 days ago [-]
I read the GP differently. I think they meant: if you are on a Mac computer, is gaming better under Linux vs macOS?
I think the answer might be yes, because it's possible to play so many more titles!
valianteffort 41 days ago [-]
I played through the entirety of Elden Ring and its DLC on my macbook pro through GPTK which is a pretty modern and demanding game. Don't think that would be possible on asahi.
pmarreck 40 days ago [-]
How would I use GPTK to play some arbitrary Windows game?
That’s true, but many titles are 32bit and Apple removed 32 bit support, causing these titles not to run. It’s a real bummer, because there is no technical limitation.
sleepycatgirl 41 days ago [-]
That's why the new WoW64 mode in wine is exciting. Even if the system doesn't support 32 bit binaries, you can still run 32bit windows software
MobiusHorizons 38 days ago [-]
Very useful, I hadn’t heard of that. I think it must not be shipped by default in steams built in proton support, but I will look into it.
GeekyBear 41 days ago [-]
Crossover and Whisky run 32 bit PC games just fine.
Wowfunhappy 41 days ago [-]
Is there a way to run Control or Cyberpunk on macOS?
fl0id 41 days ago [-]
Yes. Haven’t tried those games, but on apple silicon whisky app emulates with gameporting toolkit + wine/proton. For intel silicon I think it was also possible but not sure.
Wowfunhappy 41 days ago [-]
Oh, wow, I did not realize how many games worked with this:
You are forgetting the increasing number of titles targeting Vulkan directly.
GeekyBear 41 days ago [-]
That is an extremely niche use case on Windows.
fl0id 41 days ago [-]
Yeah,can’t tell you how it works exactly but it’s quite good
talldayo 41 days ago [-]
But if anyone can name a non-Windows platform that does it better, I'll wait!
cdogl 41 days ago [-]
> FTA: "While many games are playable, newer AAA titles don’t hit 60fps yet."
You’re lucky to get 60fps playing a fairly undemanding game on MacOS, even on hardware that is otherwise a dream.
For example, Baldur’s Gate 3 is barely playable on my M3 MacBook Pro at well below native resolution with all settings turned down. It’s a brilliant game but hardly cutting edge graphically.
Graziano_M 39 days ago [-]
I play BG3 on my M1 at 4K just fine…
endorphine 41 days ago [-]
Do you use Wine or Proton?
GeekyBear 42 days ago [-]
Emulation has unavoidable overhead.
For instance, Alyssa mentions in this post that most emulated games will need at least 16 Gigs of RAM at minimum.
In addition, native ARM games on MacOS don't have the additional overhead of emulating a different CPU architecture and Graphics API.
However, that doesn't take away from this emulated support being an amazing achievement.
jillesvangurp 41 days ago [-]
> most emulated games will need at least 16 Gigs of RAM at minimum
That's because the RAM is shared with the GPU and most of these games would require a GPU with at least 2-4GB on top of the normal system requirement to have at least 8GB. So, 8GB of RAM would be cutting it close on a mac since part of that would have to be sacrificed for the GPU.
GeekyBear 41 days ago [-]
Alyssa lays out the reasoning in the linked blog post.
They are running emulated games in their own separate virtual machine, because Intel games expect a 4k page size and the OS is running with a 16k page size.
Virtual Machines require their own chunk if memory overhead, so the resource usage can't help being higher than a native MacOS game's would be.
nottorp 41 days ago [-]
> at least 16 Gigs of RAM at minimum.
And the minimum is pretty minimum. A 16 Gb arm mac will go into yellow memory pressure while running emulated games, I've noticed.
dagmx 41 days ago [-]
No, you’ll still get better performance, more features supported and lower overhead running with Game Porting Toolkit currently.
That includes raytracing support and heterogeneous paging support which are two things Alyssa calls out explicitly herself. Not to mention the VM overhead.
That’s not to say Alyssa’s work is not very impressive. It is. But GPTk is still ahead.
That’s not even including the other aspects of Mac support that Asahi still needs to get to. Again, very impressive work, but the answer to your question is No.
risho 41 days ago [-]
i haven't tested it extensively but i tried dark souls 2 on parallels and there were vertex explosions making it unplayable, using crossover and whisky it was a jittery laggy mess. after seeing alyssa's talk i decided to load up asahi and it ran perfectly max resolution 60 fps locked. gaming on macos in my experience has been unplayable to the point where i gave up even trying. after my experience with ds2 i think that it's going to be significantly better.
dagmx 41 days ago [-]
What backend did you use? You get very different results if it defaults to MoltenVK versus d3dmetal
DS2 comes in both DX9 and DX11 flavours. The latter should work better with d3dmetal and is more comparable to what proton is doing.
risho 41 days ago [-]
i never tried to change between dx9 and 11 in parallels or crossover/whisky since i didn't know that was possible, so i was using whatever is default. that said i tried messing with all of the wine settings and it didn't seem to make a difference. i even messed with stuff like esync and msync (or whatever they were).
nottorp 41 days ago [-]
How well do soulsbornes run on windows anyway?
My strong conviction is that From is pretty much technically inept when it comes to Windows ports so I just play their titles on console...
An emulated title that is in itself a not so great port will have trouble ofc...
risho 41 days ago [-]
it works on asahi without issue. that is with x86 to arm translation, directx to vulkan translation, windows to linux translation and 4k page to 16k page translation running in a virtual machine.
as for how well fromsoft games run on windows you might have been right 12 years ago when dark souls 1 came out initially. it was a mess at the time, but souls games have been running just fine on windows(and linux for that matter) for years. it's only on macos that it is a mess. this has nothing to do with fromsoft and everything to do with macos.
nottorp 35 days ago [-]
> you might have been right 12 years ago when dark souls 1 came out initially
When it came out initially for windows I had already done two playthroughs so just did ... not ... care. I just read it's a crap port in the news.
> souls games have been running just fine on windows(and linux for that matter) for years
Maybe. For like 4 years I ran my PCs without a dedicated video card because crypto and chip crisis. The whole PS5 with an extra controller cost less than an equivalent PC video card at the time :)
[I do have a video card now, but only because someone paid me to write neural network code.]
m463 42 days ago [-]
If you mean "I have a mac, is it better to run linux to game?"
Then there's a case for it, since you can run AAA games that apple + macos doesn't support / allow.
GeekyBear 41 days ago [-]
Nothing prevents you from running games under emulation on MacOS.
Apple and Wine provide the tools, and apps like Whisky make them easy to use.
> Essentially, this app combines multiple translation layers into a single translation tool. It uses Wine, a translation layer that allows Windows apps and games to run on POSIX-based operating systems, like macOS and Linux. It also uses Rosetta and the Game Porting Toolkit, which are two official Apple tools that allow x86 programs to run on Apple Silicon and serve as a framework for porting Windows games to macOS, respectively.
Normally, this sort of process would require users to manually port games to Mac. But by combining Wine, Rosetta, and the Game Porting Toolkit, this can all happen automatically.
However, as aleays, running games under emulation has a performance cost.
kergonath 41 days ago [-]
You’d need to compare with what can be done on macOS including with things like crossover and the GPT. AFAICT, the Linux side is making progress, but still more games can be run from macOS.
talldayo 41 days ago [-]
> AFAICT, the Linux side is making progress, but still more games can be run from macOS.
I don't believe that's true. According to ProtonDB, 80% of the top-1000 most-played games on Steam are confirmed working on Linux: https://www.protondb.com/dashboard
I haven't seen any source documenting nearly similar success rates with Mac but I also haven't seriously tried gaming on Apple Silicon.
whimsicalism 41 days ago [-]
steam deck is x86
talldayo 41 days ago [-]
What a coincidence! So are a variety of Macs that shipped with hardware supporting Linux and Vulkan on day 1.
russelg 41 days ago [-]
Yes, but this thread is about Asahi Linux, which is for M series Macbooks. Not x86.
achandlerwhite 41 days ago [-]
The Mac efforts rely on MoltenVK for and Vulkan needs which itself relies on the underlying Metal API. As I understand it Asahi/Honeykrisp driver for Vulkan does not rely on the Metal API so it actually can do more conformant Vulkan than Crossover/Whisky can. For example tranform feedback and other geometry shader stuff will work on Asahi. MoltenVK is working on it, but not there yet.
dagmx 41 days ago [-]
You’re ignoring D3DMetal which is what is most commonly going to be used and equivalent to what Proton is doing to convert D3D to VK.
Most games are D3D. A very small minority are Vulkan from the get go.
achandlerwhite 41 days ago [-]
On many games I have tried DX => DXVK => MoltenVk => Metal is significantly faster than DX => D3DMetal. For example XCOM2 is about twice the frames per second (yeah it has an official Mac version but it is even slower).
whimsicalism 41 days ago [-]
I will have to check this newest development out, but as someone who dual boots Asahi and MacOS - up until now MacOS with Crossover has definitely been the best experience, if you are willing to pay
42 days ago [-]
ojdon 42 days ago [-]
Yeah it has been for a while. The steam deck runs Linux out of the box.
Valve and open source devs have put a lot of effort over the years on projects like Photon which is a translation layer for Windows games.
zdragnar 42 days ago [-]
The question was "better on Linux on a Mac", meaning specifically Asahi Linux.
The correct answer is no, not yet anyway.
Linux running on x86 with proton is still the bee's knees for most games though.
spease 42 days ago [-]
> on a Mac
Right. It sounds like the Asahi devs have implemented APIs which aren’t available under stock MacOS.
Back when I was actively developing for Freespace, we had a Linux port that had a better framerate than Windows (the game’s original platform).
fl0id 41 days ago [-]
Afaik they are emulating, which you can do on macOS too. Still great that it works with Linux
theLiminator 42 days ago [-]
Better on Linux on mac (as compared to macos) maybe?
brookman64k 42 days ago [-]
Proton, not Photon. ;-)
Here is a list with games and their support status: https://www.protondb.com/
bee_rider 42 days ago [-]
The M-series chips from Apple have some special hardware to help emulate x86 with near-native performance, right? I wonder if they take advantage of those features (actually I forget exactly what the features were).
I mean this is an incredible achievement either way. Everything is emulated, but they are still running AAA games. Wow.
sumuyuda 42 days ago [-]
They are using it:
Other than the page size issue, FEX and Rosetta are comparable technologies (both are emulators, despite what Apple marketing might have you believe). Both FEX and Rosetta use the unique Apple Silicon CPU feature that is most important for x86/x86_64 emulation performance: TSO mode. Thanks to this feature, FEX can offer fast and accurate x86/x86_64 emulation on Apple Silicon systems.
If every layer of abstraction and emulation is set up to allow it to pass through. It still seems really impressive to me, like lining up a bunch of targets and shooting an arrow through to get multiple bullseyes or something, haha.
dontdoxxme 42 days ago [-]
Hardly, the benefit of binary is if everything lines up once, it always will. It’s not an analog world with pesky things like wind resistance.
thfuran 41 days ago [-]
Maybe if you happen to own the control stack from hardware, OS, drivers, to client software and are willing to never change any of it once you get things lined up.
saagarjha 41 days ago [-]
It’s not really all that hard
ramon156 41 days ago [-]
Would you say this is not impressive work? Or how come you're saying it's not hard?
saagarjha 40 days ago [-]
It’s just exposing a couple bits in ACTLR_EL1 to userspace, nothing to it really
rowanG077 42 days ago [-]
Why not? In fact they are using it right now.
bee_rider 42 days ago [-]
I think the comment was saying “there isn’t any reason they can’t.” Which is true in theory, but in the practice it seems to be a lot of stuff to line up.
mikhael28 42 days ago [-]
Fantastic! A great proof of concept on Linux - lots of AAA gaming is already possible on Mac with Crossover and/or Parallels or VMWare Personal, which is free! While I have a Steam Deck, gaming on Mac works for me - I refuse to play Baldurs Gate 3 on a controller.
dcchambers 42 days ago [-]
I know it's an extremely un-Apple-like thing to do, but I really wish Apple would team up with Valve to work on Proton, and bring full Proton support to MacOS.
jsheard 42 days ago [-]
Bringing Proton to Mac would involve either Apple making amends with Khronos and supporting Vulkan, or Valve making the substantial effort to port Proton to Metal natively, or doing DirectX-to-Vulkan-to-Metal translation with MoltenVK. None of those sound very likely or optimal to me.
Besides, the main reason Valve is investing so heavily in Linux and Proton is so their destiny isn't tied to someone else's platform. MacOS is just another someone else's platform like Windows is, with the same threat of getting rug-pulled by a first-party app store that spooked Gabe Newell[1] into investing in Linux in the first place.
Apple already provides their Game Porting Toolkit which includes a D3D12 to Metal translation later for Wine, and it has been integrated into user-friendly Wine distributions like Crossover since last year. There's not much Proton has to offer over what's already available.
dcchambers 41 days ago [-]
My understanding about the game porting toolkit is that it requires developers to specifically modify their game in order to make their game compatible.
The magic of Proton from a consumer point of view is that it just works for basically every game, sans those with Kernel-level anticheat stuff. This means thousands of old games that haven't been updated in years will work.any games that don't have active developers.
So Apples solution works for new games but isn't a practical option for compatibility for existing games.
wtallis 41 days ago [-]
The stated intended purpose of the game porting toolkit is to enable developers to modify their games. But the software actually being shipped includes what is literally a Wine GPU backend, which is usable by (and already used and bundled by) consumer-facing Wine applications like Crossover. If you go to Codeweavers, download any Crossover for Mac from the past year (Sep. 27, 2023 according to their release notes), you're getting a tool that includes the D3D to Metal layer from Apple's Game Porting Toolkit.
dcchambers 41 days ago [-]
Huh, TIL, thanks!
fl0id 41 days ago [-]
There is things like whisky app which makes it a more general thing like proton
whimsicalism 41 days ago [-]
crossover experience does not require manual modification by developer
dcchambers 41 days ago [-]
TIL about Crossover. Thanks!
jasomill 41 days ago [-]
Also note that Codeweavers, Crossover's developer, is a major contributor to both Wine and Proton, so there's a great deal of, um, crossover between these projects.
41 days ago [-]
duskwuff 42 days ago [-]
I wouldn't hold my breath. Valve is still bitter about Apple deprecating i386 support back in 2019.
zaptrem 42 days ago [-]
Don’t forget Apple’s GamePortingToolkit based on Crossover/Wine and the open source client for it Whisky. I think it supports most games Linux Proton does now.
cherryteastain 42 days ago [-]
You can hook up a monitor, mouse and keyboard to your Steam Deck to be fair.
WithinReason 41 days ago [-]
BG3 is the only RPG I would play on a controller, it's very well done. You can also connect a keyboard and monitor to the Steam Deck, BG3 runs at 1080p high locked to 30FPS
opan 41 days ago [-]
>While I have a Steam Deck, gaming on Mac works for me - I refuse to play Baldurs Gate 3 on a controller.
Personally 99% of my Steam Deck usage is with it docked. I do mostly use a controller, but also have it hooked to the same USB switch as my PC so I can hit a button to move my keyboard and mouse over.
Baldur's Gate 3 is the first game I ever ran on my Deck that did not run very well, though. Most stuff I've played runs at 60fps at my external monitor's 1920x1200 resolution. That in addition to not liking the gameplay on BG3 much made me not continue with the game, though I may revisit it someday.
nottorp 41 days ago [-]
> I refuse to play Baldurs Gate 3 on a controller
I think you picked as an example one of the games that actually has a native Mac version?
Or is it a well hidden wine package? I've played it start to finish on Macs only and it looked too smooth to be emulation to me.
jack_pp 41 days ago [-]
truth is macs have such a small market share for gaming that it ain't worth the effort
Which is an attempt to collapse the stack so that fewer translation and virtualisation stages are needed.
bni 41 days ago [-]
This is great, hope it takes off
amoss 41 days ago [-]
I'm slightly confused after reading about page alignment. Why would a 16k page be less aligned than a 4k page causing assumptions about pointers within those pages to break? The 4k pages on x86 are aligned on 4k boundaries, are the 16k pages on M1 aligned on <4k boundaries?
y1n0 41 days ago [-]
There are more 4k boundaries than 16k boundaries. The issue is code compiled for 4k boundaries running on a 16k system.
amoss 41 days ago [-]
I'm missing something here. Assuming there are pages at 0k, 16k, 32k etc - all of those pages are aligned on 4k boundaries as 4k > 16k. So code written with the assumption that its pages are 4k aligned should have that assumption met when running with 16k pages. It is still early here and I have only had one cup of coffee. Am I misunderstanding something really obvious?
dezgeg 41 days ago [-]
x86 app might mmap 8kb, then munmap the second 4kb and expect that to work. But not possible on 16k pages.
amoss 41 days ago [-]
ah ok, so it would not be pointer alignment inside the pages but instead the assumption that page +4k is a page.
MBCook 41 days ago [-]
I was a little confused by that in the article as well. It being a granularity issue makes more sense to me.
macrolime 41 days ago [-]
Does this mean we're closer to getting GPU support on Docker on Apple devices?
May I use this space to ask the question: is the M3 substantially different from the M1 and M2 that it is not supported?
pbasista 41 days ago [-]
From what I understand, one of the factors to not focus on Asahi Linux on M3 for now is the lack of an M3 Mac Mini which supposedly makes the development easier.
wmf 41 days ago [-]
The M3 GPU added a bunch of features including ray tracing. The "dynamic caching" sounds like a big change to local memory which could require serious driver changes.
M3 GPU uses a new instruction encoding, among other things. Also, it has a new memory partitioning scheme (aka. Dynamic Caching), which probably requires a bunch of changes to both the driver interface and the shader compiler. I hope the Asahi team will get to publishing the details of M3 soon, I have been curious about this for a while.
gilgoomesh 41 days ago [-]
I don't know how different but it apparently has dramatically improved hardware shaders compared to earlier M chips so I'm guessing that a lot of this might be different, there.
aykevl 41 days ago [-]
M3 and M4 haven't been supported yet because they weren't a priority (looks like they've been focusing on gaming support for the last year or so).
and yet how do i install this gaming support on nixos?
pxc 41 days ago [-]
You'd have to package FEX :D
For the kind of person who wants to run NixOS on Apple Silicon or do Linux gaming on Apple Silicon in the first place, that's probably interesting and not too hard
but if you're allergic to that, you might be able to figure something else out with Box64, which is already packaged in Nixpkgs
x86_64 gaming on NixOS is of course well supported and has been for a long time. There's a 'native' package that I've always used and the Steam Flatpak is also available and works as well as it does anywhere
whimsicalism 41 days ago [-]
we are talking about asahi linux. i think it is pretty clear that nixos isn’t supported like a first class citizen because you have to do a fair bit of work to make all of the more recent userspace fixes work on NixOS. i run NixOS Asahi so I know.
it was easier when Arch was a first class citizen but the advice nowadays you get upon encountering a problem on Arch is to switch to Fedora
IntelMiner 41 days ago [-]
Perhaps if the NixOS folks want better support they should invest more time in keeping up with Asahi Fedora?
The developers can use what they want. Marcan famously used Gentoo for many years
pxc 40 days ago [-]
> you have to do a fair bit of work to make all of the more recent userspace fixes work on NixOS
Is it fundamentally different from any other Nix packaging work in some way?
psanford 42 days ago [-]
I'm a little sad that this has seemingly taken precedence over all other hardware support. M3 support, dp-alt mode, making the microphone work are all things that I was hoping were going to land in the past year.
pbasista 42 days ago [-]
I understand the sentiment. But the people who could work on the Asahi Linux graphics stack are generally not the same as the people who could e.g. bring up Asahi Linux on M3 chips.
I would not consider the lack of activity in some Asahi Linux areas to be a conflict of priorities. It is in my opinion mostly a result of these lacking areas naturally attracting less developers capable of moving them forward.
porphyra 41 days ago [-]
The M3 GPU is a lot different and has a bunch of new features like ray tracing, so the super talented team working on the Asahi Linux graphics stack might have a lot of work ahead of them to support the M3's GPU fully as well.
God I wish I was smart enough to help out with Asahi Linux...
nxobject 41 days ago [-]
Chipping into their Patreon helped me feel at peace with not being smart enough!
talldayo 41 days ago [-]
It's an Apple chip with no documentation and zero existent driver code to reference. You have to set realistic expectations here, and acknowledge that not every contributor is going to have the domain-specific knowledge required to make everything work. It's nothing short of a divine miracle that it has working Vulkan drivers you can download within a half-decade of it's release.
If you want more, you'll have to take it up with Tim Cook or God (both have a nasty habit of ignoring us little guys). Also an option: not using a laptop that treats Linux as a threat to it's business model.
WD-42 41 days ago [-]
I’m not sure why you are being downvoted. This is the truth people who buy Apple hardware need to hear.
dadoum 41 days ago [-]
Alyssa Rosenzweig already talked a bit about that on her Mastodon. She said that after having worked to implement a GPU drivers, it was annoying that she never had the time to quite finish them. On each device release, she had to support the new device instead of polishing what she got.
floydnoel 42 days ago [-]
I'm aware of no better way to see your desired features land in open source than to build them yourself. That is the power of open source, nobody can stop you!
zarathustreal 42 days ago [-]
[flagged]
kelnos 41 days ago [-]
Perhaps the people who aren't willing or able to learn those skills shouldn't complain about what the people who do have decided to focus on.
floydnoel 41 days ago [-]
i don't hate to be the one to tell you, but skills and context can be learnt. personally, i have found no better way to learn skills than to work on something i care about.
kergonath 41 days ago [-]
Sure, and it’s the same for quite a lot of people. It does not mean that anyone can do it, for a whole lot of reasons.
floydnoel 40 days ago [-]
anyone CAN do it
whimsicalism 41 days ago [-]
honestly with chatgpt i don’t think not learning can really be an excuse anymore.
not saying have it write the code, but just recursively asking for explanations and resources can get you up to speed on tons of things
porphyra 41 days ago [-]
I do hope that LLMs learn more from the Asahi Linux team's code and their amazing blog posts, in order to provide better guidance for new systems programmers.
fl0id 41 days ago [-]
Yeah good luck with that in systems programming or anything complex. You’re not gonna get far.
Philpax 41 days ago [-]
I guarantee you'll get much further than you would have previously done in the same amount of time, just by virtue of it being able to point you in the right direction. You don't need perfection when learning, you need a wayfinder, and it can do that just fine.
fl0id 41 days ago [-]
It won’t point you in the right direction though. At least in my experience. It will only give very superficial answers. And fe just trying to write rust - it will try to explain the error message but most of the time says nothing new and to find out how to fix it you will have to read docs and understand things the old way anyway. At least in my experience
Philpax 41 days ago [-]
What can I say, Claude's been good to me for both computer science and Rust :-)
whimsicalism 41 days ago [-]
your experience is not my experience and i have done my share of systems programming
vincentpants 41 days ago [-]
AFAIK the M3 is going to take a lot longer as the asahi team leverages apple silicon in their CI which means mac mini servers and the M3 generation never got their mac mini. Of all the generations to finally take the plunge into apple silicon, I had to choose the weird one... (typing this on an M3 mbair and not on linux sigh)
Good grief what an uphill battle. It’s amazing there are any devs willing to put up with Apple hardware at all.
opan 41 days ago [-]
Have you considered selling your machine and getting an M2 of some sort?
WD-42 41 days ago [-]
I mean this is the nature of the beast with arm and apple. It’s a closed system. There are some devs that are going to be willing to go through the effort just for the challenge of it, but most are just going to use x86/linux because you don’t have to actively fight against the vendor.
andrewmcwatters 42 days ago [-]
I think at the moment, this is probably the only way to feasibly game on a Mac. Crossover and other Wine-based apps as well as Parallels are... not really truly possible. If you bought the top-of-the-line MacBook Pro 16-inch, 2021 with M1 Max and tried to play anything reasonably modern on it, you'd find the performance is basically not playable .
whimsicalism 41 days ago [-]
I’ve been able to play a few games with crossover (like overwatch 2) fine. Whisky also works for some stuff.
I also run Asahi so will have to check this out to compare
tbillington 41 days ago [-]
I beat elden ring on m1 pro using Whisky :)
JeffeFawkes 41 days ago [-]
I've been having good luck on my M1 Max MBP with Whisky, which uses Apple's game porting toolkit: https://getwhisky.app/
dancemethis 42 days ago [-]
Where's the real inspiration for Asahi, Fandaniel in FFXIV?
rowanG077 42 days ago [-]
> Asahi means “rising sun” in Japanese, and it is also the name of an apple cultivar. 旭りんご (asahi ringo) is what we know as the McIntosh Apple, the apple variety that gave the Mac its name.
hentrep 42 days ago [-]
I noticed the URL was updated for this post. Previously it linked to asahilinux.org which showed an anti-HN manifesto from the HN referral. Curious as I haven’t seen this before. Seems it has been covered by previous commenters: https://news.ycombinator.com/item?id=36227103
How can the site even detect where a user is coming from? Browsers leaking this information seems like a huge privacy issue to me.
robin_reala 42 days ago [-]
Referer (misspelled in the spec) has been a part of HTTP from day 1.
ginko 42 days ago [-]
Feels crazy this isn’t disabled by default
mananaysiempre 42 days ago [-]
See[1] the Referrer-Policy header, <meta name="referrer">, <a referrerpolicy> and <a rel="noreferrer">.
But generally, webmasters have found it useful to know who caused their server to fall over^W^W^W^W^W^W is linking to their pages. This was even used as a predecessor to pingbacks once upon a time, but turned out to be too spammable (yes, even more so than pingbacks).
After the HN operators started adding rel=noreferrer to links to the Asahi Linux website, Marcan responded[2] by excluding anyone who has the HN submit form in their browser history, which feels like a legitimate attack on the browser’s security model—I don’t know how it’d be possible to do that. (Cross-origin isolation is supposed to prevent cross-site tracking of this exact kind, and concerns about such privacy violations are why SRI has not been turned into a caching mechanism along the lines of Want-Content-Digest, and so on and so forth.) ETA: This is no longer in place, it seems.
Visited links have always looked different from unvisited ones, and the moment you could customize how links looked via CSS, browsers also had to implement styling for visited links specifically.
Modern browsers put a lot of care into making the changes to those styles observable to the user, but not to Javascript.
This is an extremely hard problem, and browsers have had a lot of security issues related to this behavior. Nowadays, you can only apply a very limited subset of CSS properties to those styles, to avoid side-channel timing attacks and such.
This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
mananaysiempre 42 days ago [-]
Ah. Ahhh[1]. I see.
<!doctype html>
<style>a { color: white; background-color: white; } a:visited { color: black; }</style>
<body><a href="https://example.com/abracadabra" onclick="return false">you are a bad person</a>
> This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
How do they stop you from using Canvas to see the output and send it back?
zamadatix 41 days ago [-]
Canvas can't "see the output", it only sees what is drawn in it (which is not a set of HTML tags, it's JS commands).
The screen recording/screen sharing API can be used for this but security is the reason you have to give explicit permission to the site before it can do this.
miki123211 41 days ago [-]
IIRC, Firefox had a bug where this exact scenario was possible, I think you needed to embed the link in html embedded inside an SVG, which was displayed in the canvas, and then access the bitmap. You could e.g. make the link black if visited and white otherwise, and then the number of white versus black pixels in the bitmap would tell you whether the link was visited or not.
There was also that asteroids game / captcha where links were white/black squares and your goal was to click all the black ones. Of course, clicking a square revealed that you knew the square was black, which meant the URL under it was in your history.
zamadatix 40 days ago [-]
If you go back far enough there weren't even protections against this sort of thing at all! E.g. you could just say a visited link style was 1px taller then measure that. The protections had to be added in after the fact (often with special case logic for what's allowed to be styled or read on :visited) once security became a major concern!
bigstrat2003 42 days ago [-]
Referer does have legitimate uses. For example, back in the day people would use it to detect if someone embedded an image from their site on another site. SomethingAwful famously used to respond to any such requests with goatse, and forums I was on had very strict "don't link to SA images" rules as a result.
I think that using referer to try to deliver manifestos to users of another site is kinda childish, but so it goes. Every tool can be put to good or bad uses.
dylan604 42 days ago [-]
It's only slightly less childish than the current WP drama.
paraboul 42 days ago [-]
This is part of the web DNA. Pages linking pages and being aware about it. Origin can still disable it.
Smar 42 days ago [-]
There is little hope to get it disabled when an ad company is running running the most popular ad platf... Erm, the world wide web browser.
jsheard 42 days ago [-]
The Referrer-Policy header lets a server tell the browser how much referrer information to pass on when following links, all the way down to nothing at all if desired. Chrome does respect that, and they also followed other browsers in changing the default to "strict-origin-when-cross-origin" a few years ago which truncates the referrer path when leaving to a different domain, so they only see the domain the visitor came from rather than the specific page like they used to. Can't really fault Google in this case.
There's a handy addon for Firefox called Privacy Settings that can take care of that. Explicitly adds and option to have the referers be not sent, and a quick way of re-enabling it, in case it breaks a website. Because of course that happens too.
42 days ago [-]
xbar 42 days ago [-]
Thank you
Alyssa Rosenzweig
Asahi Lina
chaos_princess
Davide Cavalca
Dougall Johnson
Ella Stanforth
Faith Ekstrand
Janne Grunau
Karol Herbst
marcan
Mary Guillemard
Neal Gompa
Sergio López
TellowKrinkle
Teoh Han Hui
Rob Clark
Ryan Houdek
dyingkneepad 42 days ago [-]
Thank not only these people but also their employers for funding the work.
41 days ago [-]
42 days ago [-]
shmerl 41 days ago [-]
[flagged]
fl0id 41 days ago [-]
Yeah yeah great, now please m3 support, or maybe before that support for internal mic and external displays/dp-alt. Pretty please?
(Not complaining happy about any progress)
Philpax 41 days ago [-]
kinda sounds like you're complaining, though
fl0id 41 days ago [-]
Fair point :)
wly_cdgr 41 days ago [-]
Ok, but why would a hardcore Linux person want to play games that embody everything they hate about Windows in their mode of production, data gathering practices, politics, etc?
_fizz_buzz_ 41 days ago [-]
People use Linux for a wide variety of reasons and those reasons are very often not ideological. If the only reason to use Linux was ideological, Linux wouldn't be as popular as it is.
Philpax 41 days ago [-]
linux users like to have fun too
Also, there are plenty of Windows-only games that aren't subject to those practices. Free games, itch.io games, GOG games, etc. There's a big world out there!
lmm 41 days ago [-]
> there are plenty of Windows-only games that aren't subject to those practices. Free games, itch.io games, GOG games, etc. There's a big world out there!
Those games are generally not AAA by definition, and often either already have a Linux build released, run acceptably under traditional emulation, or both.
viraptor 41 days ago [-]
It's just a platform which is an available option. Nobody forces you to play games that you don't agree with for any reason.
umanwizard 41 days ago [-]
There are lots of reasons to run Linux. Not everyone who runs it is a free software ideologue.
nottorp 41 days ago [-]
Stay away from the companies requiring their own game store / "club" (i'm looking at you Rockstar) account and you're likely to be fine.
41 days ago [-]
paulryanrogers 41 days ago [-]
It is shocking the effort required to have a good gaming experience on Apple computers (excluding iOS). They always struck me as agnostic to games, yet in recent years it appears to border on open hostility.
kalleboo 41 days ago [-]
Apple has always been anti-gaming. It's been in the companies DNA since the first Mac was derided as a "toy" for having a graphical user interface, and they overcompensated trying to make it a business machine with no games.
About once a decade someone inside of Apple who is really passionate about games pushes some project through - you had GameSprockets in the 90's, you had someone convincing Valve to port Half-Life, you have GamePortingKit now, but it's just not in the companies culture to give game developers the long-term support they need.
fl0id 41 days ago [-]
They made gameportingkit, which got made into whisky app. So not totally hostile
snarfy 41 days ago [-]
It was Jobs specifically that was anti-gaming. I'm not sure where Cook stands.
It will never happen, but my dream is for the Asahi devs, Valve, and Apple to all get together to build out a cross-platform Proton to emulate and play games built for Windows on both x86 and ARM hardware running Linux.
A Steam Deck with the performance and power efficiency of an M-series ARM chip and the entire library of games that run on Proton is just...dreamy.
Her output is incredible.
I recognize it’s a hell of an ask, but I think Alyssa could pull it off.
https://github.com/Whisky-App/Whisky
Sometimes you’ve just gotta tip your hat.
The end game for Valve isn't Steam Deck 2 or 3 (which is statistically impossible for Valve to produce), but for Steam to be on everything.
Most of the studios that own those games, and target POSIX like OSes on mobile phones and game consoles, are yet to bother with GNU/Linux versions for SteamOS.
What Valve want is the dissolution between platform/architecture and store. By my eye, it's the driving force of their efforts, more so than them selling hardware or being the open source good guys. Not to undervalue their work in helping make Linux a first class citizen for gaming, but the core of their business model is getting people to engage with their store, full stop, and being able to sell their games on Android (and elsewhere) would massively extend their reach.
This may go both ways too, there's also been indications that Valve have been tinkering with Waydroid, meaning Steam could also become a store for Android-native games.
I don't think Valve wants to be at the mercy of Microsoft and their policy & technical decisions.
In order for Microsoft to rug-pull the technology (which is quite different from rug-pulling the business model), they'd have to break compatibility on Windows itself. Video games remain a major reason for home users to run Windows. Making ABI-breaking changes to Win32 or DirectX is just not very likely to happen. And if it did happen, it would be a boon to Valve and not a harm.
The biggest risk (and this would be a classic Microsoft move, to be fair) I can foresee is aggressive API changes that make it hard for Valve/Wine/Proton to keep up but also make it hard for game developers not to. I'm not exactly sure what this would look like, and a lot of the core technologies are pretty stable by now, but it's a possibility. It's not, however, going to harm anything that already exists.
Making SteamDeck use windows wouldn't impact prices much, Microsoft is really friendly for putting windows by OEMs. Could even run modified to act like current steam deck.
Instead, SteamDeck is there to drive up testing on Proton or straight forward porting to Linux, which just availability on Linux and the previous steam machine didn't drive up
If future versions of Proton break compatibility with older Windows apps, you can use different old versions of Proton for individual games. Steam makes this very easy on Linux, but rarely is it necessary.
I don't foresee many Linux distros breaking compatibility with Wine, which is good, as some devs argue Win32 is the only stable ABI on Linux. [1]
I don't foresee legal issues either, as Wine has been around for 31 years, and its corporate sponsors have included Google in the past. I've seen no indication that the project is on shaky legal grounds.
Microsoft could always create a new API that Wine doesn't yet support, but good luck getting developers to use it -- they've tried many times, but not much has stuck, and most devs just stick with Win32. [2]
1. https://blog.hiler.eu/win32-the-only-stable-abi/
2. https://news.ycombinator.com/item?id=36060678
The steam deck is 100% usable without leaving 'game mode' even a single time. Something that is genuinely impossible using Windows as a base. That's the important part
Also when it comes to breaking proton support (Which does happen) Valve + GloriousEggroll give you access to plenty of older and special versions. Surely that's better than rolling back entire software?
My game doesn't work -> I go to protonDB -> Users saying use X Proton Version or Y ProtonGE version -> I switch the layer used in steam
Hard to imagine a simpler process than that
By supporting Proton, they are guaranteeing that modern and retro Windows games will be playable on Linux far into the future. Trying to get the next Call of Duty to support Linux natively is, quite literally, a waste of everyone's time that could possibly be involved in the process. I cannot see a single salient reason why Linux users would want developers to release a proprietary, undersupported and easily broken native build when translation can be updated and modified to support practically any runtime.
- CD Projekt Red: released Witcher 2 on Linux, didn't for Witcher 3.
- iD Software: released Doom 3 on Linux, didn't for Doom (2016) or Doom Eternal.
- Epic Games: released Unreal Tournament 2004 on Linux, but didn't for Unreal Tournament 3 or Fortnite. (A Linux port was being worked on for UT3, but it ended up getting cancelled.)
- Larian Studios: released Linux version of Divinity: Original Sin, didn't for Divinity: Original Sin 2 or Baldur's Gate 3
Many studios over the years have made native Linux versions, and many studios stopped because the cost of porting exceeded the revenue it generated. Proton didn't exist when Unreal Tournament 3, Witcher 3, Doom (2016), or Divinity: Original Sin 2 released, so Proton wasn't the reason those studios stopped developing Linux titles -- they stopped because it made no financial sense to continue to make them.
Now, with Proton, 79% of the top 1000 games on Steam are gold or platinum rated on ProtonDB. If you're fine with minor issues, 88% are silver rated or better. For the Steam Deck in particular, there are 5,500 verified games, and 16,526 verified or playable games. So I'd argue Proton is doing quite a lot for people gaming on GNU/Linux machines, since they now have access to a solid majority of the top 1000 games on Steam, both on a Linux desktop and on a handheld.
We aren't in the 90s anymore. Win32 has stalled, Microsoft has a regulatory gun to their head and Wine's compatibility (at least in the domain of games) is extremely good, good enough to allow for a commercial product to be a success while being entirely reliant on it. In what way is any of this comparable to what happened with OS/2 outside of "it runs Windows applications"?
- Automated Personnel Unit 3947
Half life 1, 2… hm.
Ok we’ll make three HL2 episodes to follow that up.
Ep I. Ep II. Uhhhh… and let’s stop there, just like forever I guess.
Portal 1. Portal 2.
Left4dead. L4D2.
Team Fortress. TF2.
Counterstrike. CS2. Oh shit we’re releasing a third one, we might have to use the number three finally, oh no… I’ve got it: CS:Go!
Regardless, point stands: they hate the number 3.
Then again, all kinds of companies take liberties with naming including numbers. Look at Windows 7 (12th major release), Windows 10 (successor to Windows 8), the game Battlefield 2 (third in the series), Battlefield 3 (three games after BF2), Battlefield 1 (after the release of BF4), etc.
I empathize if you don't like any version of Windows newer than 7 or XP, but it's time to let the dream of running them forever go. It's not weird when software doesn't support the 2009 version of an operating system anymore in 2024. If they never dropped support, it would be difficult to take advantage of improvements that occurred in the last 10 years, because we'd forever be stuck in baggage.
Of course when it's feasible everybody loves software that really never does drop support, like 7-zip, which I think happily still works on Win9x without KernelEx... but I'd rather 7-zip stopped having serious security issues than continued to work on old Windows versions.
However, it is Microsoft more than anyone else that has decided to stop supporting those operating systems. Windows XP does not have support for any modern version of TLS (only TLS 1.0). There's no good way to support a browser-based app like Steam on a platform that cannot natively provide a secure connection to a modern web server.
There is not such a hard reason to drop Windows 7 support (again, except that Microsoft no longer supports it) but there are security-relevant APIs that are only available starting in Windows 10 which means special patches would have to be maintained just for Steam on Windows 7 to continue working securely.
CodeWeavers released an annoucement when Gaming Portal Toolkit was announced.
https://www.codeweavers.com/blog/mjohnson/2023/6/6/wine-come...
You sure there was any kind of commercial agreement? Doesn’t look like it.
On top of that, Apple's DX to Metal code is not re-distributable. So yes, this sounds like more of the same from Apple.
And the root of the whole browser wars thing was microsoft making an absolute dog of a browser for Mac OS X when it came out and then refusing to support it. lmao.
It was the file manager as well as the browser and it was incredibly capable. By far the most advanced GUI file manager of its time. And a pretty fast and pleasant browser, although the compatibility was hit and miss. (Those were Flash and IE-dominated days as I recall them.)
A lot of what I loved about Konqueror is captured in Dolphin. I don't think I need my web browser to be a file manager... maybe that concept was just a 90s fever dream. But I miss Rekonq. Maybe I should revisit Konqueror.
'Default' KDE apps are often so well thought-out and complete that I never feel the need to deviate from them, and it's not unusual for me to install them on other operating systems when possible. I feel this way about Dolphin, Okular, Ark, Kate, Gwenview, Klipper, and Konsole/Yakuake, too (even though there are several great new terminal emulators out nowadays). And KWin! God, KWin's configurability is so good and it has some really killer compositor effects for productivity that are still unmatched.
Also a quick correction, there was no IE5.5 for OSX. That was for Windows and used a diff rendering engine.
I also remember Safari on Windows, which was convenient for many reasons.
https://raw.githubusercontent.com/apple/homebrew-apple/refs/...
0 chance they upstream anything. So in a way they are already benefitting from valves work.
The real reason Apple is ahead is because they're paying for more expensive more advanced nodes for their CPUs. I you compare CPUs on similar node sizes, you'll see that AMD and Intel are basically caught up architecturally in perf/W metrics.
https://www.notebookcheck.net/Intel-Lunar-Lake-CPU-analysis-...
https://youtu.be/ymoiWv9BF7Q
Intel was losing badly to one or the other at all TDPs. I don’t get the impression that’s changed much. (Even if it has, I can’t remember the last time I encountered a non-xeon intel machine with working hardware and drivers (for any OS, and I tried Windows, Linux and macs).
But I guess there was never a time when an open graphics standard stood as the leader. Maybe during a brief stint in the Windows Vista era at best.
Sure it's a great design, but I believe x86-64 will catch up once again now with everyone using TSMC.
AIUI, if you want the most flops per die, you'll buy x86 - probably the 128-core Xeon for enterprise money. But that's not what's best for hand-held gaming.
AAA titles are typically GPU-bound anyway. More CPU flops may not offer much benefit.
Yes, but actually no. The Steam Deck is playing at extremely low resolutions. Rendering at 720p and 30fps is (on paper) 8x less demanding on the GPU than rendering a native 1440p60 experience. You can fully get by without having a powerful dGPU, which is why the Steam Deck is really able to play so many titles on a weak iGPU.
The problem is translation. Cyberpunk 2077 runs fine on a 25 watt mobile chip that uses x86, which is why the Deck even costs less than $1000 in the first place. If you try to put a mobile ARM CPU in that same position and wattage, it's not going to translate game code fast enough unless you have custom silicon speeding it up. There's really no reason for Valve to charge extra for a custom ARM design when COTS x86 chips like AMD's would outperform it.
For x86 PC games (which pretty much all games are, today), ARM is at a substantial disadvantage, period. The IPC and efficiency advantages are entirely lost when you have to spend extra CPU cycles emulating AVX with NEON constantly. If there were ARM-native games on Windows then things might be different, but for today's landscape I just don't see how ISA translation is better than native.
1) everything standardized, like it or not (note: I do not), on the Windows API, and it has remained relatively stable, which is important because
2) Linux-native games I've had, have become un-executable over time without semi-regular maintenance, and Windows games running on whatever version of Proton they best work with do not have that drawback
> Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute.
Is this potentially a part of why Apple doesn't want to support Vulkan themselves? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance?
(I realize performance is still relatively fast in practice, which is awesome!)
Yes, it's a big reason.
I tried to port the yuzu switch emulator to macos a few years ago, and you end up having to write compute shaders that emulate the geometry shaders to make that work.
Even fairly modern games like Mario Odyssey use geometry shaders.
Needless to say, I was not enough of a wizard to make this happen!
If you are talking about Vulkan, that is much more complicated. My guess is that they want to maintain their independence as hardware and software innovator. Hard to do that if you are locked into a design by committee API. Apple has had some bad experience with these things in the past (e.g. they donated OpenCL to Kronos only to see it sabotaged by Nvidia). Also, Apple wanted a lean and easy to learn GPU API for their platform, and Vulkan is neither.
While their stance can be annoying to both developers and users, I think it can be understood at some level. My feelings about Vulkan are mixed at best. I don't think it is a very good API, and I think it makes too many unnessesary compromises. Compare for example the VK_EXT_descriptor_buffer and Apple's argument buffers. Vulkan's approach is extremely convoluted — you are required to query descriptor sizes at runtime and perform manual offset computation. Apple's implementation is just 64-bit handles/pointers and memcpy, extremely lean and immediately understandable to anyone with basic C experience. I understand that Vulkan needs to support different types of hardware where these details can differ. However, I do not understand why they have to penalize developer experience in order to support some crazy hardware with 256-byte data descriptors.
I honestly wonder how much the rallying around Vulkan is just that it is a) newer than OpenGL and b) not DirectX.
I understand it’s good to have a graphics API that isn’t owned by one company and is cross platform. But I get the impression that that’s kind of Vulkan‘s main strong suit. That technically there’s a lot of stuff people aren’t thrilled with, but it has points A and B above so that makes it their preference.
(This is only in regard to how it’s talked about, I’m not suggesting people stop using it or switch off it to thing)
Tessellation falling short is just classic Apple, though. Shows how much they prioritize games in their decision making, despite every other year deciding they need a AAA game to showcase their hardware.
(apologies for the crude answer. I would genuinely be interested in a technical perspective defending the decision. My only conclusion is that the kind of software their customers need, like art or editing, does not need that much tessellation).
If you’re using geometry shaders, you’re almost always going to get better performance with compute shaders and indirect draws or mesh shaders.
A lot of hardware vendors will handle them in software which tanks performance. Metal decided to do away with them rather than carry the baggage of something that all vendors agree is bad.
It takes up valuable die space for very little benefit.
If the reason they don't support it in hardware is because they don't want to support it in software, then the logic gets a bit circular.
I'm interested in which came first, or if it's a little of both.
Geometry shaders are generally considered less necessary in modern graphics pipelines due to the rise of more flexible and efficient alternatives like mesh shaders which can perform similar geometry manipulation tasks with often better performance and more streamlined workflows
[0] https://github.com/KhronosGroup/MoltenVK/issues/1524
We (CodeWeavers) are doing this in (a fork of) MoltenVK, and Apple’s D3DMetal is as well.
https://github.com/KhronosGroup/SPIRV-Cross/pull/2200 https://github.com/KhronosGroup/SPIRV-Cross/pull/2204
Interestingly, Apple was on the list of the initial Vulkan backers — but they pulled out at some point before the first version was released. I suppose they saw the API moving in the direction they were not interested in. So far, their strategy has been a mixed bag. They failed to attract substantial developer interest, at the same time they delivered what I consider to be the best general-purpose GPU API around.
Regarding programmable tessellation, Apple's approach is mesh shaders. As far as I am aware, they are the only platform that offers standard mesh shader functionality across all devices.
Although its true that they are an optional feature (as is tessellation).
Which seems like an ineffective move when you have no market share.
So, wait, does this mean that gaming is better on Linux, on a Mac?
Wine is wonderful and with Valve's help it only got better.
But why would gaming on a mac be better? Maybe one day, but for now:
FTA: "While many games are playable, newer AAA titles don’t hit 60fps yet."
I think the answer might be yes, because it's possible to play so many more titles!
https://docs.getwhisky.app/game-support/index.html
I had assumed the lack of Vulkan on macOS was a major issue. Apparently not!
---
[1]: https://github.com/KhronosGroup/MoltenVK
PC games use DirectX as their graphics API, so you need something that can translate from DirectX to the native graphics API your OS is running.
On MacOS you'd be translating from DirectX to Metal and Apple provides the emulation software (D3DMetal) as part of the Game Porting Toolkit.
On a Steam Deck, Proton uses Vulkan on Linux as the native graphics API, so in that case you are translating from DirectX to Vulkan.
> DXVK (which translates Direct3D 8, 9, 10 and 11 calls to Vulkan on the fly), vkd3d-proton (which translates Direct3D 12 to Vulkan)
https://emulation.gametechwiki.com/index.php/Proton
You are forgetting the increasing number of titles targeting Vulkan directly.
You’re lucky to get 60fps playing a fairly undemanding game on MacOS, even on hardware that is otherwise a dream.
For example, Baldur’s Gate 3 is barely playable on my M3 MacBook Pro at well below native resolution with all settings turned down. It’s a brilliant game but hardly cutting edge graphically.
For instance, Alyssa mentions in this post that most emulated games will need at least 16 Gigs of RAM at minimum.
In addition, native ARM games on MacOS don't have the additional overhead of emulating a different CPU architecture and Graphics API.
However, that doesn't take away from this emulated support being an amazing achievement.
That's because the RAM is shared with the GPU and most of these games would require a GPU with at least 2-4GB on top of the normal system requirement to have at least 8GB. So, 8GB of RAM would be cutting it close on a mac since part of that would have to be sacrificed for the GPU.
They are running emulated games in their own separate virtual machine, because Intel games expect a 4k page size and the OS is running with a 16k page size.
Virtual Machines require their own chunk if memory overhead, so the resource usage can't help being higher than a native MacOS game's would be.
And the minimum is pretty minimum. A 16 Gb arm mac will go into yellow memory pressure while running emulated games, I've noticed.
That includes raytracing support and heterogeneous paging support which are two things Alyssa calls out explicitly herself. Not to mention the VM overhead.
That’s not to say Alyssa’s work is not very impressive. It is. But GPTk is still ahead.
That’s not even including the other aspects of Mac support that Asahi still needs to get to. Again, very impressive work, but the answer to your question is No.
DS2 comes in both DX9 and DX11 flavours. The latter should work better with d3dmetal and is more comparable to what proton is doing.
My strong conviction is that From is pretty much technically inept when it comes to Windows ports so I just play their titles on console...
An emulated title that is in itself a not so great port will have trouble ofc...
as for how well fromsoft games run on windows you might have been right 12 years ago when dark souls 1 came out initially. it was a mess at the time, but souls games have been running just fine on windows(and linux for that matter) for years. it's only on macos that it is a mess. this has nothing to do with fromsoft and everything to do with macos.
When it came out initially for windows I had already done two playthroughs so just did ... not ... care. I just read it's a crap port in the news.
> souls games have been running just fine on windows(and linux for that matter) for years
Maybe. For like 4 years I ran my PCs without a dedicated video card because crypto and chip crisis. The whole PS5 with an extra controller cost less than an equivalent PC video card at the time :)
[I do have a video card now, but only because someone paid me to write neural network code.]
Then there's a case for it, since you can run AAA games that apple + macos doesn't support / allow.
Apple and Wine provide the tools, and apps like Whisky make them easy to use.
> Essentially, this app combines multiple translation layers into a single translation tool. It uses Wine, a translation layer that allows Windows apps and games to run on POSIX-based operating systems, like macOS and Linux. It also uses Rosetta and the Game Porting Toolkit, which are two official Apple tools that allow x86 programs to run on Apple Silicon and serve as a framework for porting Windows games to macOS, respectively.
Normally, this sort of process would require users to manually port games to Mac. But by combining Wine, Rosetta, and the Game Porting Toolkit, this can all happen automatically.
https://www.xda-developers.com/hands-on-whisky-macos-gaming/
However, as aleays, running games under emulation has a performance cost.
I don't believe that's true. According to ProtonDB, 80% of the top-1000 most-played games on Steam are confirmed working on Linux: https://www.protondb.com/dashboard
I haven't seen any source documenting nearly similar success rates with Mac but I also haven't seriously tried gaming on Apple Silicon.
Most games are D3D. A very small minority are Vulkan from the get go.
Valve and open source devs have put a lot of effort over the years on projects like Photon which is a translation layer for Windows games.
The correct answer is no, not yet anyway.
Linux running on x86 with proton is still the bee's knees for most games though.
Right. It sounds like the Asahi devs have implemented APIs which aren’t available under stock MacOS.
Back when I was actively developing for Freespace, we had a Linux port that had a better framerate than Windows (the game’s original platform).
I mean this is an incredible achievement either way. Everything is emulated, but they are still running AAA games. Wow.
Other than the page size issue, FEX and Rosetta are comparable technologies (both are emulators, despite what Apple marketing might have you believe). Both FEX and Rosetta use the unique Apple Silicon CPU feature that is most important for x86/x86_64 emulation performance: TSO mode. Thanks to this feature, FEX can offer fast and accurate x86/x86_64 emulation on Apple Silicon systems.
From: https://docs.fedoraproject.org/en-US/fedora-asahi-remix/x86-...
https://fosstodon.org/@slp/113283657607783321
Sergio Lópéz has more info in his blog
https://sinrega.org/2024-03-06-enabling-containers-gpu-macos...
https://sinrega.org/2023-10-06-using-microvms-for-gaming-on-...
Besides, the main reason Valve is investing so heavily in Linux and Proton is so their destiny isn't tied to someone else's platform. MacOS is just another someone else's platform like Windows is, with the same threat of getting rug-pulled by a first-party app store that spooked Gabe Newell[1] into investing in Linux in the first place.
[1] https://www.bbc.co.uk/news/technology-18996377
The magic of Proton from a consumer point of view is that it just works for basically every game, sans those with Kernel-level anticheat stuff. This means thousands of old games that haven't been updated in years will work.any games that don't have active developers.
So Apples solution works for new games but isn't a practical option for compatibility for existing games.
Personally 99% of my Steam Deck usage is with it docked. I do mostly use a controller, but also have it hooked to the same USB switch as my PC so I can hit a button to move my keyboard and mouse over.
Baldur's Gate 3 is the first game I ever ran on my Deck that did not run very well, though. Most stuff I've played runs at 60fps at my external monitor's 1920x1200 resolution. That in addition to not liking the gameplay on BG3 much made me not continue with the game, though I may revisit it someday.
I think you picked as an example one of the games that actually has a native Mac version?
Or is it a well hidden wine package? I've played it start to finish on Macs only and it looked too smooth to be emulation to me.
Which is an attempt to collapse the stack so that fewer translation and virtualisation stages are needed.
https://www.theverge.com/2023/10/30/23938676/apple-m3-chip-g...
Alyssa said in her talk that they'll probably get it working in 6 months or so: https://www.youtube.com/watch?v=pDsksRBLXPk&t=2932s
https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rose...
Wine has beta support for 32-bit Windows applications on 64-bit-only wine, but it's not default.
They also address it: https://docs.fedoraproject.org/en-US/fedora-asahi-remix/x86-...
Modern C++ with move semantics is a lot more easy to reason about and memory safe than C99, IMO.
Since it's a greenfield project, they didn't have to worry about the nasty baggage of legacy C++ spaghetti that kills most projects.
Just because you prefer "simple" C99 doesn't mean they do :)
https://news.ycombinator.com/newsguidelines.html
For the kind of person who wants to run NixOS on Apple Silicon or do Linux gaming on Apple Silicon in the first place, that's probably interesting and not too hard
but if you're allergic to that, you might be able to figure something else out with Box64, which is already packaged in Nixpkgs
x86_64 gaming on NixOS is of course well supported and has been for a long time. There's a 'native' package that I've always used and the Steam Flatpak is also available and works as well as it does anywhere
it was easier when Arch was a first class citizen but the advice nowadays you get upon encountering a problem on Arch is to switch to Fedora
The developers can use what they want. Marcan famously used Gentoo for many years
Is it fundamentally different from any other Nix packaging work in some way?
I would not consider the lack of activity in some Asahi Linux areas to be a conflict of priorities. It is in my opinion mostly a result of these lacking areas naturally attracting less developers capable of moving them forward.
God I wish I was smart enough to help out with Asahi Linux...
If you want more, you'll have to take it up with Tim Cook or God (both have a nasty habit of ignoring us little guys). Also an option: not using a laptop that treats Linux as a threat to it's business model.
not saying have it write the code, but just recursively asking for explanations and resources can get you up to speed on tons of things
Ah yeah, here's the post: https://social.treehouse.systems/@marcan/112277289414246878
I also run Asahi so will have to check this out to compare
But generally, webmasters have found it useful to know who caused their server to fall over^W^W^W^W^W^W is linking to their pages. This was even used as a predecessor to pingbacks once upon a time, but turned out to be too spammable (yes, even more so than pingbacks).
After the HN operators started adding rel=noreferrer to links to the Asahi Linux website, Marcan responded[2] by excluding anyone who has the HN submit form in their browser history, which feels like a legitimate attack on the browser’s security model—I don’t know how it’d be possible to do that. (Cross-origin isolation is supposed to prevent cross-site tracking of this exact kind, and concerns about such privacy violations are why SRI has not been turned into a caching mechanism along the lines of Want-Content-Digest, and so on and so forth.) ETA: This is no longer in place, it seems.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
[2] https://social.treehouse.systems/@marcan/110503331622393719
It isn't, at least not in the way you think.
Visited links have always looked different from unvisited ones, and the moment you could customize how links looked via CSS, browsers also had to implement styling for visited links specifically.
Modern browsers put a lot of care into making the changes to those styles observable to the user, but not to Javascript.
This is an extremely hard problem, and browsers have had a lot of security issues related to this behavior. Nowadays, you can only apply a very limited subset of CSS properties to those styles, to avoid side-channel timing attacks and such.
This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
How do they stop you from using Canvas to see the output and send it back?
The screen recording/screen sharing API can be used for this but security is the reason you have to give explicit permission to the site before it can do this.
There was also that asteroids game / captcha where links were white/black squares and your goal was to click all the black ones. Of course, clicking a square revealed that you knew the square was black, which meant the URL under it was in your history.
I think that using referer to try to deliver manifestos to users of another site is kinda childish, but so it goes. Every tool can be put to good or bad uses.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
Also, there are plenty of Windows-only games that aren't subject to those practices. Free games, itch.io games, GOG games, etc. There's a big world out there!
Those games are generally not AAA by definition, and often either already have a Linux build released, run acceptably under traditional emulation, or both.
About once a decade someone inside of Apple who is really passionate about games pushes some project through - you had GameSprockets in the 90's, you had someone convincing Valve to port Half-Life, you have GamePortingKit now, but it's just not in the companies culture to give game developers the long-term support they need.