Valve is testing ARM64 support for popular games

191 pointsposted 10 months ago
by haunter
(notebookcheck.net)

201 Comments

modeless

10 months ago

It seems pretty clear to me that this is for Valve's long-awaited standalone VR headset, Deckard. What other reason would they have to support Gorilla Tag on ARM? https://x.com/SadlyItsBradley/status/1837210246076588500

Compatibility with your existing Steam library out of the box will be a huge competitive advantage for Deckard over Meta Quest.

dagmx

10 months ago

Imho it’s unlikely this is for natively running on a standalone headset. The overhead of translation alone would be just burning already limited compute budgets.

The other games on their list are too demanding for untethered play in the wattage one would have on a face mounted device. IMHO gorilla tag here is just a red herring.

IMHO this is just valve hedging the bet that ARM machines become more popular , and future steamdeck like devices might use ARM.

It would make sense that they test SteamVR running with proton and tethered to a headset rather than directly connected.

Imho, that’s the more straightforward explanation for this. The game is just a test bed for tethered play.

modeless

10 months ago

I think you're right that they wouldn't ship Gorilla Tag this way. For a game that big I'm sure they can work with the developer to ship a native version. But for internal testing of a headset it would make sense to use this version in advance of availability of a native port.

The games that will ship this way will probably mostly be non-VR games that would never get ported otherwise. So you can play your Steam library full of non-VR x86 Windows PC games on a giant virtual screen in VR.

dagmx

10 months ago

I think you’re perhaps over indexing on the one game in the list. The other games in the list have no VR mode at all. So they could run standalone in a flat screen view, but with fairly poor performance.

Gorilla tag also has an ARM version already for Quest. So why would valve not just start from there? The Quest line of products use effectively the only SoC that Valve would have access to anyway for the XR space.

Imho desktop and tethered playing are far more likely targets. I think Deckard might show up someday but it’s become a vessel for everyone’s hopes and dreams.

jorvi

10 months ago

> Imho it’s unlikely this is for natively running on a standalone headset. The overhead of translation alone would be just burning already limited compute budgets.

I wonder if with both Windows and Valve getting into ARM64, that will bring significant enough pressure on the market for ARM OEMs (and ARM itself) to start including a x86-transpilation mode similar to the one Apple has in their M-series of CPUs to increase the performance of Rosetta2.

dagmx

10 months ago

Afaik the Snapdragon X cores include the memory ordering mode that the M series have as well.

Log_out_

10 months ago

Could split it at the image generation layer? GPU work is done on the headset, sim is running on external machine.But then why use arm?

bloqs

10 months ago

Yeah tethered with a newer generation steam link wireless protocol would be great. They move everything forwards whenever they try something new

jillesvangurp

10 months ago

I don't think this is about the hardware necessarily. They probably make more money from the Steam store and there are some notable ARM based platforms where you currently can't use Steam and where they are not able to sell games.

Macs would be a big juicy target, for example. If they can get emulation working well enough with proton on that, that's a huge market. Lots of people with disposable income on there that could be buying lots of games. And Apple is doing similar things as well so there might be some opportunity to tap into what they are doing.

modeless

10 months ago

As much as it sounds like it would make sense, I haven't seen any hints that they are developing Proton for macOS. That seems like it would be evident from open source changes, if it was happening.

I think Valve is reluctant to get any closer to Apple, or any large platform owner for that matter. They want to stay independent and own their own destiny. They even tried to get away from Microsoft with Steam Machines. It failed back then, but the Steam Deck is the continuation of that effort.

Novosell

10 months ago

It isn't a huge market though. Mac has never been particularly big for gaming, they've always come in very low on the steam hardware survey.

Now, post-ARM, it's beat by Linux even.

FroshKiller

10 months ago

I don't think the Steam hardware survey is representative of the market size. Most people with Macs are accustomed to games that should run just fine on them never getting released, which means there often isn't any point to installing Steam on a Mac in the first place. Therefore they wouldn't be represented even though they are gamers, they spend money, and they have Macs.

I don't have a PC for personal use, but I do have a lot of game consoles, an M1 MacBook Pro, and an M2 Mac mini. There are lots of games like Pizza Tower that look fun to me, do not have a Mac version, but do have a Switch version. So I wind up spending money on Switch games that would've gone to Steam if the publisher had bothered with a macOS release.

While I do have Steam installed on my M1 and M2, I rarely launch it because I've only bought eight games off Steam in two years because of this dynamic, meaning I haven't even participated in the survey myself. My Steam account is over 20 years old and has a healthy library from when I was a PC gamer. I'd say my money's on the table, but my money's in Nintendo's wallet. But I'd really rather be buying macOS versions!

jillesvangurp

10 months ago

That's because Steam barely works on modern macs. After they killed 32 bit support, most of my games stopped working. Even at the best of times, only a fraction of the games worked on mac. And now with essentially all macs running arm processors, the only macs left running steam are from last decade. So all these surveys prove is that a market that they barely supported wasn't very large.

And you forget that one of the largest gaming platforms out there is the iphone. Which also doesn't show up in the steam hardware survey because steam doesn't run on it. The iphone market proves that there is a gaming market for typical Apple users. A very big market even. People that spend a lot of money on their phone also seem to like spending a lot of money in the app store. And mostly on games. Apple rakes in billions via the app store.

If Steam were to get Mac support to the same level it is on Linux, most of the games would start working and there are a shitload of Apple PCs and laptops out there that would be able to run that.

Novosell

10 months ago

People who play phone games wont convert to playing desktop games. My mother-in-law has spent untold amounts of money on candy crush, on her iPhone, has a 10 year old windows desktop and talks shit about her daughter playing videogames games from time to time. If you've got some data saying the correlation is very high, alright. But I don't believe it is.

Also, where is Apple's responsibility in all this? Steam this, Steam that. Apple changes arch, doesn't support vulkan and removes 32-bit support and then it's Steam's job to chase Apple? EA, Ubisoft, CD Project, Epic and Actiblizzard all also have store fronts and don't care to support mac. They could all be asleep behind the wheel, true. Or it could be that Apple makes it too annoying to support a platform that would barely yield any sales.

If Steam, a tiny company in comparison, and Codeweavers, also an tiny company in comparison, can get games to run on Proton+Linux then I'm pretty sure that Apple, with a little help from their trillion dollars, can manage something. But they also don't care cause Steam wont give 30%, which is Steam's fault of course.

sangnoir

10 months ago

iPhones and iPads too. Valve opening a Steam store on iOS devices is the stuff of Apple's nightmares.

happymellon

10 months ago

Only in Europe.

Please give us 30% of Steam. Tnx.

chithanh

10 months ago

It seems pretty clear to me that the main target of this is ARM Chromebooks, at least for now. As these are the only products currently shipping in any relevant numbers where this makes sense.

gpderetta

10 months ago

An ARM based steam deck seems more likely.

chithanh

10 months ago

But unlike ARM Chromebooks, an ARM Steam Deck does not exist today, and will not exist until at least November 2025 per Valve statements.

https://www.bloomberg.com/news/articles/2023-11-09/new-steam... (archived link w/o paywall: https://archive.md/VWvsW )

gpderetta

10 months ago

I think it is pretty clear that Valve plays the long game. Proton existed for years before SD was released.

dagmx

10 months ago

Proton didn’t exist in a vacuum though. It existed for Valves previously failed vision of the Steam Machine. Those were actual product lines that existed (briefly) to go along with Proton.

The Steam Deck was Valve finally getting sick of nobody doing what they wanted, and technology getting to where they could do something more interesting than just another desktop.

gpderetta

10 months ago

Proton came well after the steam machine failed. It was plan B.

dagmx

10 months ago

I could have worded it better but that’s my point. It was sort of their third attempt to make Linux gaming a thing (steamOS 2 + proton) before they finally came up with a compelling product of their own.

mmcnl

10 months ago

Since you're talking volume: what about MacBooks?

chithanh

10 months ago

MacBooks certainly have volume, but Wine/Proton on macOS is facing serious technical challenges which they only started to address (Wine 9.0 with WoW64 was only released in January). Chromebooks are much lower hanging fruit.

zamadatix

9 months ago

Valve contracts ~a dozen developers from Codeweavers (same folks that develop Codeweavers and the downstream open source project WINE) for Proton and they've had 32 bit Windows executables working on macOS (despite the native limitations) for years.

hsjdhdvsk

10 months ago

Arm windows laptops?

chithanh

10 months ago

You don't need Proton for that, and the article talks about Valve testing proton-arm64.

madeofpalk

10 months ago

This does not seem clear to me. My initial guess would be ARM based Steam Deck (or similar handhelds).

But generally, what is clear to me is that ARM is slowly becoming a lot more viable for general purpose computing. Apple's completely made the shift, and Microsoft seems to be persuing it for laptops at least finally. ARM seems like a great match for handhelds, if it wasn't for the compat issues.

LorenDB

10 months ago

And with Waydroid support, games designed for Quest or other Android-based headsets could run on Deckard as well.

snvzz

10 months ago

With SteamOS, they solved their dependency on Windows.

Now, they're trying to stop being tied to x86.

ARM64 is being tested because hardware is already widely deployed, but not being tied to x86 is the important part. Enabling e.g. RISC-V as well.

pjmlp

10 months ago

They are fully dependent on Windows Games developed for Windows.

They are only working really hard not to pay for Windows OS licences.

The day they actually support native Linux games, instead of doing Windows API translation is when I believe they are actually serious about Linux games, and not saving OS licenses.

Scramblejams

10 months ago

Valve got a scare with Windows 8 that they could be pushed off the platform.[0] It became clear to them that they were just guests in a house owned by Microsoft. That was in 2012, the first Steam Machine (running Linux) came out 3 years later and they've been working at it ever since.

It's not about saving the cost of a license, it's about guaranteeing their own survival.

As for "supporting native games," I take that to mean "sufficiently incentivize game devs to port their games to Linux." How would that work, or did you have something else in mind?

[0] https://www.bbc.com/news/technology-18996377

pjmlp

10 months ago

Currently their survival depends mostly on Windows games, developed for Windows.

It would work by placing carrots and whips in place for anyone that wants to target their shop, just like console vendors do.

user

10 months ago

[deleted]

a2128

10 months ago

The cost of developing and maintaining Proton, Linux driver improvements, and their own Arch-based OS has probably exceeded the amount they saved by not shipping Windows on Steam Deck.

But what they got in return is a much more usable gaming operating system that doesn't constantly pester you about switching to Edge, using Copilot or draining all your battery for an update while you game

What they got in return is freedom from Microsoft's arbitrary OEM hardware requirements like having a front camera for Windows Hello, or having a TPM

What they got in return ultimately is leverage. As sibling comment mentioned, they were in fear that they could be kicked off of Windows by Microsoft. Now, Microsoft is the one in fear that if they ever kick Steam off, gamers now have a perfectly functioning alternative operating system to switch to.

albrewer

10 months ago

> The cost of developing and maintaining Proton, Linux driver improvements, and their own Arch-based OS has probably exceeded the amount they saved by not shipping Windows on Steam Deck.

So far. Depending on Microsoft's continued benevolence is probably not a great business strategy when you're as big as Valve. You don't want to be caught with your pants down when MS wants their pound of flesh from your $8 billion company.

acdha

10 months ago

Isn’t that basically the last paragraph of the comment you replied to?

pjmlp

10 months ago

Assuming Windows games, developed for Windows, keep runing in Proton and Microsoft doesn't come up with specific Windows API requirements not possible in Proton, like plugging into Pluton that is now a requirement for upcoming PCs.

throwaway9524

10 months ago

Seems this sentiment is coming up in every recent Proton related thread. Despite all the counterarguments offered each time.

The simple reality is that there are decades worth of Windows games that will never have a Linux version. Because of the studios being gone. Because of the source code being lost. Because of the licensing issues for dependencies, assets, music. If not for the Valve efforts people would always need a copy of Windows to play a good chunk of their libraries. At which point why bother with Linux? But with Proton the calculus changes. Most of those Windows-only games are now fully playable on Linux. Many people no longer need Windows and that's a huge win for desktop Linux adoption.

By this logic Apple should not have developed x86 translation for its latest Macs because it showed they are not serious about the platform and disincentivized devs from providing native Arm ports. Except we know that's not what happened.

pjmlp

10 months ago

Apple developed the x86 translation layer for its own OS, not a third party OS.

throwaway9524

10 months ago

I get the reasoning from your other replies. If Microsoft extends Win32 with some new API that cannot be reimplemented in Proton then Valve is screwed. So you want them to require a native Linux version from every game published on Steam.

However I really do not think Valve is in a position to dictate such terms. They have multiple competitors both in distribution and console space. Big names are already publishing on their own stores. Small indies can move to itch.io. Everyone else can switch to Epic. Steam Deck is already underpowered compared to recent Windows based handhelds. If it stops supporting Windows games via Proton then it is as good as dead.

I understand your idealism. But a step like this would kill gaming on Linux much quicker than anything Microsoft could do. Because Valve is the only big distributor even remotely interested in it. In contrast Epic is absolutely hostile to Linux. And they're the ones to gain the most users in case Steam fails.

kelnos

10 months ago

> They are fully dependent on Windows Games developed for Windows.

Sure, but they don't want to be dependent on Windows itself. If they can run all those Windows games on another OS, that's a win. Proton is pretty amazing, even if it's not 100%.

And if game devs for some cataclysmic reason abandon Windows, they'll figure that out too.

pjmlp

10 months ago

More like Valve will eventually get its OS/2 moment.

missblit

10 months ago

Steam has supported native Linux games for a decade.

pjmlp

10 months ago

It has, yet the focus is all about Proton.

gpderetta

10 months ago

Valve has little control on what other companies target. Their previous push for native gaming produced very little results: Valve ported all their titles, a few minor publishers released native titles and some porting companies ported some AAA titles, but it was only a drop.

Proton has caused a significant increase in Linux playable games. The side effect is that it effectively killed porting companies.

edit: also all porting companies were effectively using their proprietary equivalent of proton (although often inferior) .

flohofwoe

10 months ago

TBH running through a Win32/DX API shim isn't much different than running through SDL, yet Linux games using the SDL are considered "native" but Win32 games running through Proton are not?

(the Win32 and DX APIs are also much more straightforward to use than wrestling directly with X11, Wayland, Vulkan and the Linux audio API flavour of the month)

anthk

10 months ago

SDL handles everything for you.

On Windows, good luck with running DirectX 6, 7, 8, and some DX9 and Direct Draw games under Windows > 8 without issues.

Direct Draw games will lag even under an i5.

sph

10 months ago

Yet Proton game work better and with greater performance than most native ports, which are created once by third-party teams (i.e. Feral), never properly tested or rarely updated.

Soon Wine will have Wayland support and 99% of those ports that no one is willing to update will remain stuck on X11.

flohofwoe

10 months ago

Good luck running a >20 year old native Linux game on a modern Linux distro without recompiling.

A Proton like layer would also totally make sense on Windows, assuming that support for older Windows APIs is better in Proton than on Windows itself (which isn't a far fetched assumption).

anthk

10 months ago

LD_LIBRARY_PATH it's your friend. For the rest, either AOSS or osspd to map OSS into ALSA or into Pulseaudio/Pipewire.

As for the missing libraries, if you can fetch some old Debian DVD images (just the first DVD) it will run fine.

navjack27

10 months ago

All of this already exists on Windows. They're already drop in DLL replacements that smooth out compatibility with older versions of graphics APIs among other APIs. And old support for old games actually isn't that bad on Windows 11. No one has heard of this game, but I could just boot up the old Japanese PC game Abyss Boat and it kind of just works. If I use a DLL replacement or something like dxwnd or dgvoodoo2 it's even better.

anthk

10 months ago

With a Direct Draw replacement like the one from WineD3D your game/software is not better; the game literally stop beings a Power Point presentation and gets fully playable.

But, by default, you'll get a slideshow in a game that would run screamly fast under a Pentium 3 and a Windows release from its era.

gpderetta

10 months ago

> A Proton like layer would also totally make sense on Windows

it is not full Proton, but DXVK is used on Windows as it has sometimes better compatibility and/or performance for older titles.

sph

10 months ago

Not Valve's fault that user-space Linux is run by a bunch of unpaid headless chicken with no overarching vision, sense of momentum and direction, while Win32 is a rock-stable API that games are already using.

Until there is a Linus figure that coordinates the userspace and organises a common platform API with long term support for closed-source software, Proton is the only pragmatic choice.

Valve want to get off Windows ASAP, not necessarily waste money chasing windmills driven by silly ideology that native is better.

I love Linux, I have used it for 25 years, and even I accept that native games run WORSE than their Proton counterpart.

ChocolateGod

10 months ago

> unpaid headless chicken with no overarching vision

systemd, GNOME, mesa etc all have developers who are being paid by companies for their work (Red Hat, Microsoft, Canonical, SUSE etc). That said, you're not wrong on the 'no overarching vision' part, see Wayland.

> Linus figure that coordinates the userspace and organises a common platform API

Flatpak with the freedesktop runtimes are just this, that said some companies (e.g. Canonical) are trying to sabotage these efforts and Ubuntu not shipping with Flatpak is the biggest hurdle.

sph

10 months ago

Flatpak is not a common userspace library, just a set of sandboxed functions (i.e. portals).

What we need is something that groups Qt/GTK, pipewire, part of systemd, part of flatpak, part of Wayland into a single library, a bit like Win32 is. And the guarantee that it remains stable even for closed source projects. For example Linux is free to change its internals and requires everything to be open, so drivers can be adapted whenever the APIs change. This is not good enough for a desktop API.

ChocolateGod

10 months ago

The free desktop runtimes for Flatpak made by XDG (the group that standizes the desktop protocols) are a common userspace library.

sph

10 months ago

I get what you mean, but pinning commits does not make for a standard, unified ecosystem.

imtringued

10 months ago

Maybe because there is a large backlog of old games that will never be ported to Linux? Have you considered that game developers and not valve are responsible for providing a Linux port of their game and so far have managed to do a worse job than a DirectX implementation for Linux?

The collective time spent on developing proton is probably less than a dozen high profile Linux ports.

The latest commit to proton 9.0 is three weeks ago. The latest commit to an experimental branch is 3 days ago and it is just an update of a wine version and no other commits. A lot of proton commits just update a version here and there.

The focus is certainly not on proton. It is simply very cheap to work on it, because it is highly effective. The steam deck probably cost them more software and hardware developer hours than proton.

Cloudef

10 months ago

It's unfortunate but win32 has stable ABI. Such thing can't be really said about glibc and dynamic linking. Many old linux game binaries simply don't work or need tinkering to get them work.

snvzz

10 months ago

Steam Runtime takes care of this, offering a stable platform for games to target.

Cloudef

10 months ago

Even steam runtime is hit and miss, the problems mostly come with GPU drivers / mesa incompatiblity.

Beretta_Vexee

10 months ago

the majority of users have no idea what OS is actually running on their steamdeck and don't want to worry about it. Proton makes it possible to maintain a large library of older games on the platform. Like any Steam user since Half-life 2, I must have accumulated over a hundred games in my library. I think Valve knows better than we do what users want.

YokoZar

10 months ago

So? How is a game fully running on Proton not a native game?

Wine's version of the Windows API isn't conceptually different from any other cross-platform technology here. You could make a similar purity argument against using the Unity engine since most of its games end up being primarily on Windows too.

kelnos

10 months ago

Sure, because Valve can't control what OSes other game developers target. That seems obvious?

trashface

10 months ago

I used to port games to linux (from windows). There is just a huge amount of work porting each game, even if the tech used is somewhat cross platform to begin with. Game devs in general (and the people funding them) are just not interested in doing that work; they have more than enough work just getting the game to ship on their primary target platforms. And at least back in my day, native linux ports sold extremely poorly.

Aside from that there is a huge catalog of games using DX 9-12 and other windows-specific APIs that is just never going to get ported and that even valve would never be able to get source code for. Most of that source code is essentially unobtainable and in some cases has passed through multiple IP holders such that whoever owns it now (most likely a big company like EA or microsoft) doesn't even know what they have, let alone how to build it or even where the archives are.

An additional fact is that nowadays many older games have communities that have modded them unofficially by resorting to DLL injection and other hacks - these hacks can work under proton with the windows executable, but would fail on with a native linux binary. An example is oblivion script extender and its many cousins for that family of bethesda games. Many of the more advanced mods for those games require the capabilities of those low level hacks.

boomboomsubban

10 months ago

Are you suggesting they aren't serious about Linux unless they stop selling games without a native Linux version?

kranke155

10 months ago

which would be insanity, considering the numbers...

pjmlp

10 months ago

Yes

boomboomsubban

10 months ago

Never happening, it'd destroy Steam instantly.

Even as someone who tries to predominantly buy games with a native Linux version, it's not something I really want. If I have some desire to play a game from 2008 again, I'm glad Steam will still offer me the Windows version.

jasonjmcghee

10 months ago

On my deck, I can run native Linux games

pjmlp

10 months ago

Sure, pity that the large majority on Steam library are running on top of Proton.

ywvcbk

10 months ago

Why, though? What difference does it really make besides significantly reducing the cost of “porting” games?

If anything, due to Wine, Proton etc. “Windows API” is almost a pseudo opensource way of developing cross-platform content. There are significant downsides but on the bright-side it’s extremely stable considering to most stuff on Linux.

yazaddaruvala

10 months ago

Could you help me understand why that is a pity? Seems like Valve’s adapter pattern is a great development tool to get Linux games without dev studios spending excessive dev time/money on it.

Is Proton in some way inferior to native?

mariusor

10 months ago

I can think of one thing, which might not be what parent meant: the incentive of developing for linux, or paying porters like icculus and flibitijibibo to build a native version goes out the window, and the need for their kind of craft goes away.

Frankly when the SteamDeck launched I hoped that game developers will start treating it as they do any other console and build specifically for it, but sadly Proton prevented that from happening.

timschmidt

10 months ago

I don't think Proton has prevented anything. In fact, without it, and the back catalog of Windows games it makes available on SteamDeck, I doubt the handheld would have been as popular. SteamDeck was successful enough to get a re-release in the form of the OLED model, which is a big success for a Linux handheld. The longer Valve remains committed to the platform, and the more devices they get into the hands of consumers, the more attractive native Linux games will look to developers.

mariusor

10 months ago

The people I mentioned in my comment clearly disagree with you, and frankly they have more of an incentive to be well informed about the situation. See the twitter link I posted to your comment's sibling for Ethan Lee's impressions from three years ago.

Also, I never argued against Proton having been a boon for Linux gamers, but I tried to present an opposing point of view that usually does not get taken into account.

Like I mentioned in the other comment my impression over the past 3-4 years is that the number of native linux ports has dwindled to nothing and that is most likely due to Proton making them unnecessary.

Novosell

10 months ago

In my experience, the Linux ports never got any attention from the devs either way. They'll usually have worse performance, not be on the current patch and in at least one case, Binding of Isaac Rebirth, not be compatible with the DLC as the DLC works in some hacky way on the windows version.

Without Proton the steam deck would not be popular enough to warrant any Linux ports either way. So Linux ports would be doomed regardless.

The real travesty is steam, with the recent introduction of WoW64 in Wine, is now the only software that requires me to run 32bit binaries on my desktop. Real annoying.

yazaddaruvala

10 months ago

In your opinion, why is the "trust in Proton" not considered "developing for Linux"?

Is your argument specifically about the game developer's mental model for Linux's priority, or something core about the Proton abstraction layer?

All software runs on some abstraction. So specifically, if the game developer prioritized a Linux port by explicitly testing Proton, would that be enough for you to consider the game "developed for Linux"?

mariusor

10 months ago

The consumer artifact for a game developed for a platform is a binary that can run natively on that platform.

Regarding games, that is a binary that targets the ubuntu based Steam Linux Runtime. That's what I meant when I said that devs should be able to target it as a regular console SDK.

schmorptron

10 months ago

I think it's a longer term play. Step 1) Establish a large enough non-windows userbase with great compatibility tools Step 2) Studios and especially game engine developers notice linux install base Step 3) Some tangible benefit to running natively, if only stability, pops up and the userbase is now large enough to care about it Step 4) Engines, and then games get better native support

mariusor

10 months ago

I am pretty sure you're wrong. Here's a tweet from 2021: https://x.com/flibitijibibo/status/1416118465442852869

To quote from down the conversation:

> @flibitijibibo (Jul 16, 2021): Don't look at me - I'm just trying to figure out how much time I have left, either way it's pretty clearly finite

Also some anecdata from someone that pretty much bought all native linux releases from Steam since the linux version was released: in the past 2-3 years there were barely any new ones, outside of Valve's own titles maybe.

andrewclunn

10 months ago

Sometimes (with older games) I force proton installation instead of the native port because it runs better.

arlort

10 months ago

Your comment above was about:

> The day they actually support native Linux games

Not "the day a majority of their library is linux native"

As others mentioned valve has been developing their games as linux native already, what do you expect them to do? Force every single developer to support all the platforms possible? Delete all the games not linux native?

ywvcbk

10 months ago

> They are only working really hard not to pay for Windows OS licences.

In what way are they supposed to be paying for Windows licenses? What do you even mean by that? You aren’t required to give 30% to MS to ships Windows apps (nor macOS)

If anything they are trying to build a moat, good-luck playing Xbox games on your Steam Deck if you don’t go out of your way to install Windows. Making them affectively a monopoly for now.

gpderetta

10 months ago

Valve doesn't ship Windows on the SD, hence doesn't need to pay a license for it. Nothing prevents MS for porting their launcher to SD and running the games on SD.

throwaway2048

10 months ago

all valve games are linux native, as are lots of steam releases

pjmlp

10 months ago

The point is about the large majority that runs on top of Proton.

weberer

10 months ago

All modern games developed by Valve support Linux natively. They don't have much control over what other companies do.

pjmlp

10 months ago

Yes they do, put requirements on steam like any console vendor.

Beretta_Vexee

10 months ago

There are tens of thousands of titles on Steam, developed since 2004. It's going to be a while before the majority of the catalogue is Linux native.

khorne

10 months ago

You mean all the games that aren't Valve games? How is Valve supposed to create native Linux ports for them?

pjmlp

10 months ago

Like other stores, put them into the contract.

kelnos

10 months ago

Feels like you're moving the goalposts. You said:

> The day they actually support native Linux games

They do, and have for a long time now, for nearly all of their own releases. There's not much more they can do than that; they don't control what platforms other companies want to port to.

pjmlp

10 months ago

Valve, the store owner, not Valve the game studio.

skeaker

10 months ago

Sorry, but are you saying you believe Valve is responsible for the development of every game on their store? In case you're just genuinely unaware, games are developed by a variety of people and studios completely separately from Valve.

pjmlp

10 months ago

Did I miss something, don't they own the Steam Store, SteamDeck and dictate the rules what gets sold there?

skeaker

10 months ago

Yes, and they opt to sell video games from most anyone who opts in to their store. Fundamentally, that is their business. What you're asking of them is beyond unreasonable because it fundamentally goes against what they do and it would immediately kill their business in its entirety if they stopped selling 99% of games. Then we wouldn't even get Proton and Linux would be truly dead for gaming.

What you're asking of them is akin to complaining that Apple sells tech instead of dishwashers when fundamentally that's so far from what they do that it's absurd, not to mention that if they suddenly stopped selling all tech their business would obviously die. I feel a bit foolish for even entertaining this because what you propose is so obviously outlandish to me that I'm about 85% sure you're just messing around to get a rise out of people.

potwinkle

10 months ago

What are you talking about? Practically every Valve game has a native (non-Proton) Linux port.

Every Counter-Strike, every Team Fortress, every Half-Life (even Alyx), every Portal, DOTA 2, Artifact.

pjmlp

10 months ago

I am not talking about Valve....

russelg

10 months ago

It would be great if this meant proton is coming back to macOS :)

I don't have high hopes however.

dagmx

10 months ago

Just use Whisky (https://getwhisky.app/) or CrossOver (https://www.codeweavers.com/crossover)

While it would be great if Valve did what they do on SteamOS and just manage it themselves, it’s a very minor burden to use the existing solutions to do the same.

sho

10 months ago

> Just use Whisky

You know, every 6 months or so I get a sudden hankering to play Portal or something and start down this rabbit hole. Based on your prompt, I had another look today.

So I went and downloaded this "whisky" thing. From their website: "Experience the latest titles effortlessly with Whisky!". OK. Installed.

I open it and I see a window with "bottle configuration" (wtf is a bottle?), an "open c: drive" button (???), "SteamCMD" whatever that is, "winetricks" (??) and a "run.." button which opens a file from finder (??). I have absolutely no idea what any of this is or how to proceed.

Confronted with this and the prospect of hours of research and messing around I decide I don't need to play anything all that much really.

UPDATE - ok, I decided to actually try and get it working and it's not that bad. Follow this video, basically: https://www.youtube.com/watch?v=xowJ3b-pt-U

And protip, set your system audio to 44.1khz. Cool. Portal.

I maintain the user onboarding could be MUCH more friendly.

npteljes

10 months ago

This is one of the things that Valve does very well. I even end up installing Steam on PCs that I run non-steam software on, because Proton is just that easy. I add the shortcut to Steam, choose my proton runtime (if that), click play, and the client does the rest. WHY ON EARTH is it more complicated with other launchers? No idea, and I bet that they have exactly 0 UX people among their midst. And even the programmer excuse doesn't work, that programmers are bad at this sort of thing (think "programmer art"); because programming also adopted convention over configuration in the early 2000s, 20 years ago now.

Sorry for the rant, I also hate bad UX. It makes me feel stupid for no good reason.

dagmx

10 months ago

Yeah whisky definitely exposes more of the wine underpinnings. Crossover is more user friendly but isn’t free.

Crossover are the primary developers behind WINE and transitively, Proton.

Steam just handles all the configuration elements of proton for the user but essentially it’s doing the same stuff under the hood.

whateveracct

10 months ago

Me neither, but it's a shame. Those Apple Silicon chips are solid for gaming.

shmerl

10 months ago

If Apple cared about gamers, they wouldn't have blocked proper Vulkan support. They simply don't care. A major reason to stay away from Apple if you are a gamer.

caseyy

10 months ago

It’s not the end of the world to develop for macOS and iOS. These platforms are just idiosyncratic and don’t have many serious gamers.

Neither smartphones nor Macs have been powerful or ergonomic enough to play current-generation games for decades. So the user base is almost entirely people who don’t play games.

For a developer, the juice is not worth the squeeze (and by far!). The platforms are challenging to port for and all that effort seems to result in near-zero sales. All ports seem to be almost guaranteed commercial failures.

My key point is that perhaps the platforms are now mature enough to develop for and Metal is alright. But they have not been for a long time and it’s a really bad market to target for a game developer.

Unless Apple funds your games like some other platforms do, it’s better to just blow the porting budget on something that’s at least fun. I haven’t heard of anyone’s game funded by Apple, but maybe it happens? These deals are rarely made public.

Chicken and the egg.

Just my opinion.

hot_gril

10 months ago

I feel like Apple has the opposite attitude of Microsoft's towards 3p apps in general, not just games. Mac updates will constantly break apps at least minor ways, sometimes major (like 32-bit removal).

dwaite

10 months ago

Microsoft's reluctance to break things comes from commercial entities being a big source of licenses both for desktops and backend servers. If some poorly maintained mission-critical app doesn't run on Windows 11 because it hasn't had a recompile in a decade, that means a Global 2000 company isn't able to update their workforce.

Apple considers it a partnership with developers, even if that partnership in reality is rather one-sided. If you stop maintaining your software you aren't holding up your end of the partnership. For instance, ignoring six years worth of deprecation warnings about 32 bit software going away, or seven years (and running) warnings about OpenGL support, or still shipping only Intel binaries four years after M1 launched.

But this is not how games are supported, except for subscription games like MMOs or crazy edge case labors-of-love like Starcraft. Fixes are going to be driven by a chance at new revenue, like updating to support HiDPI displays properly as part of a major DLC update. Afterthought ports (especially third party ones) like a Windows title to the Mac are even more limited in terms of ongoing support - and are often like-for-like limits to 32 bit intel only because the original developers never tried to write portable code.

shmerl

10 months ago

Gamers don't need to worry about "how games are supported" as along as they work. You can run many old games in Wine even though original developers stopped supporting them decades ago. Putting hurdles in the way of that is the opposite of supporting though and that's where Apple is causing a problem. This applies to refusal to support Vulkan as well as stuff like gutting 32-bit and OpenGL.

hot_gril

10 months ago

Sometimes it works, but the performance is worse. Like back when I had an Intel Mac, csgo was fine on Boot Camp but had noticeable input lag in macOS, and iirc under Wine it had less input lag but stuttered more. It'd be unplayable if I cared about winning, but I didn't care.

caseyy

10 months ago

It seems that way. For a long time, what Apple didn’t use or specifically wanted on their platforms didn’t get a lot of thought.

Most game engines haven’t figured out resolutions and DPI scaling for windowed full-screen games in macOS and for a long time, it didn’t seem like there were many guidelines (bare minimum) or support from Apple.

Third party is just not as important as first party to Apple, I think. Which is ironic for a company that has succeeded tremendously off the backs of 3p devs on iOS. But perhaps it’s a different strategy for each product line. And it’s probably been a good strategy to focus on certain areas and not others for them.

It’s not all bad, you can definitely port games to Macs with some effort. If it was only worth it, it would be fantastic.

Though I’ll say, I think there is a niche for casual games with excellent graphics on Macs now. This niche could be worth a lot of money by the end of the decade, just like casual mobile games.

jamesfinlayson

10 months ago

> Unless Apple funds your games like some other platforms do, it’s better to just blow the porting budget on something that’s at least fun. I haven’t heard of anyone’s game funded by Apple, but maybe it happens? These deals are rarely made public.

Maybe I'm wrong but I thought/assumed that Valve's work to get Steam and their GoldSource and Source game engines working on Mac was with some sort of support from Apple - I know they did Linux support around the same time but the extra work to get everything working on a Mac wouldn't have been trivial.

caseyy

10 months ago

Nice find, it’s true.

That’s the only avenue I see where porting a AAA-style game makes sense for a Mac financially.

Left 4 Dead 1 and 2, and several Counter-Strike games were also ported, but CS:GO was later discontinued for Macs. These were done without Apple’s money as I understand. And the discontinuation seems related to support costs on a platform that doesn’t have many gamers.

jamesfinlayson

10 months ago

Yeah I think Valve ported their whole catalogue of games, but I'm not sure what exactly happened with the discontinuation - I thought they quietly dropped the Mac support tag from all of their games two or three months ago, probably because Intel Macs haven't been sold in a few years now? Presumably they didn't want to sink more money into Mac support (they had 11 years worth of Mac usage statistics to back up their decision).

concinds

10 months ago

> I'm not sure what exactly happened with the discontinuation

They didn't update their old games with 64-bit support, and in February they dropped support for the last macOS with 32-bit support (Mojave) because 98% of Mac Steam users had updated to newer OS releases. Mojave (released in 2018) hasn't received security updates in years, and doesn't support the latest CEF, which the Steam client is based on. https://www.tomshardware.com/software/macos/32-bit-mac-holdo...

caseyy

10 months ago

I don’t think Intel v. ARM matters too much once the engine HALs support it natively, or through Rosetta 2. This to me doesn’t seem too bad.

The OS APIs and building an ergonomic experience is the challenging part. Supporting APIs is harder than it may seem. That’s graphics, sound, task scheduling and multi threading, I/O for both files and devices, and many more. All these things have different approaches on different OSes, as well as different limits of what is allowed and what is not. Different best practices and degrees of documentation, too. This all then needs to make for a good player experience and meet gamer expectations. It’s a Herculean task.

It is even harder, because many graphics APIs, for example, support different features. So either your artists must accommodate and create several versions of skeletal meshes, visual effects, and similar; or your engineers must develop new graphics technologies to compensate automatically. And if that didn’t seem hard enough, try recruiting from a pool of game graphics programmers for macOS without a hot six figures a year burning a hole in your pocket. Now consider this for other APIs, though they are often more standard and less challenging.

I could be wrong, but many corners are cut for platforms that don’t have that many players — you just can’t justify the costs it would take to do an excellent port. And that creates pretty deep and difficult to patch issues. The same is seen on games ported to Linux.

dudus

10 months ago

While this seems counterintuitive Mac makes it very convoluted to release on their platform. To the point that the low sales really don't justify. Here's a video from a game dev driving this home

https://youtube.com/shorts/qRQX9fgrI4s?si=Wg2NkJlo8r0kd9NC

caseyy

10 months ago

This is what I meant, in part, by saying how idiosyncratic the platform is. There are many more ways it is so.

I am very happy someone put the sales figures out there in the public. Not everyone can afford to if they must keep a professional relationship with Apple.

<100 sales for Mac like this guy claims are realistic numbers.

rxyz

10 months ago

> Neither smartphones nor Macs have been powerful or ergonomic enough to play current-generation games for decades. So the user base is almost entirely people who don’t play games.

Current Macs and iOS devices are powerful enough. There's a handful of developers shipping full current-gen games to both platforms.

littlecranky67

10 months ago

> It’s not the end of the world to develop for macOS and iOS. These platforms are just idiosyncratic and don’t have many serious gamers.

That could change if Apple and Valve would team up and make proton-like stuff happen (GamePortingToolkit is a first, but half-assed step). I own a MacMini M2 base model (retailed at 630€ new) for work and was surprised how well games last-gen games run on it (either Rosetta2 or GPTK+wine). With better software compatibility I could see the upcoming M4 mac mini as a serious game console contender. Smaller form factor and more silent than any console, add an Xbox/DualSense controller in the living room and you are good to go.

shmerl

10 months ago

Point is that Apple is deliberately blocking Vulkan support. Which prevents things like Wine / Proton from offering decent performance for games there (MoltenVK is not really adequate for that).

Being it's Apple, not some kind of poor entity who can claim lack of resources, I'd say they very much on purpose disregard gaming as a use case and therefore it's a strong reason to stay away from Apple to begin with if you do care about it as a user (gamer).

latexr

10 months ago

> I'd say they very much on purpose disregard gaming as a use case

Considering they made Metal, and the Game Porting Toolkit, and Game Center, and specific tabs for games in the App Stores, and Apple Arcade, and added native support for game controllers, and have dedicated sections of their keynotes to gaming, it is pretty clear they don’t disregard gaming as a use case. Tim Cook’s Apple is bad in a lot of ways, but it isn’t that stupid to ignore that lucrative of a market which fell on their lap.

What you mean is they’re not embracing gaming the way you want. Which is fine to complain about, I also would prefer a different approach, but saying they’re purposely disregarding gaming does not align with reality.

shmerl

10 months ago

> What you mean is they’re not embracing gaming the way you want

Yes. And I consider it disregarding when it comes to the needs of gamers (or users in general really). Apple's approach is always shoving in their users' faces "that's the way to do it". As I said, it's a major reason to completely stay away from them.

hot_gril

10 months ago

I just play whatever games happen to work on Mac. Which isn't a lot of them, but it's enough.

zaptrem

10 months ago

Many games that work in Wine work just fine in GamePortingToolKit (which is just an Apple-written patch on top of CrossOver which is just more patches on top of Wine)

ElFitz

10 months ago

> deliberately blocking

What do you mean by that?

shmerl

10 months ago

Unlike Linux, Windows and etc. I don't think even GPU makers can provide their own implementation of Vulkan there - only Apple can do that. And they refuse. So it can be considered a deliberate blocking.

ElFitz

10 months ago

I see. It’s possible.

I personally believe, considering their track record, it’s more likely they simply don’t care about it.

More experienced macOS and iOS developers will probably be able to confirm that Apple basically only invests efforts in what Apple wants, whatever that is, and nothing else.

pjmlp

10 months ago

Most game studios don't care about Vulkan, that is why HLSL is what everyone uses instead of GLSL.

Any game engine worth using has Metal support for ages.

gpderetta

10 months ago

That's all well and good, but no Vulkan means not DXVK or VKD3D without yet another layer of translation like MoltenVk.

flohofwoe

10 months ago

Silly argument, Vulkan also isn't available on Xbox or Playstation, yet dedicated game console platforms clearly care a lot about gaming.

There's also only a handful of Vulkan games, supporting D3D11 and D3D12 on macOS would make a lot more sense. But in reality, porting to a different 3D API isn't what makes or breaks a game port.

shmerl

10 months ago

I see nothing silly about it. Bringing other bad examples of lock-ins doesn't excuse Apple in the least. Personally I'd stay away from the above too.

> There's also only a handful of Vulkan games

There are a ton of games that are Vulkan games through vkd3d-proton and dxvk. Which was the above point.

flohofwoe

10 months ago

So if Apple would provide a similar D3D shim on macOS, all D3D games would suddenly become "Metal games"?

If Apple would implement Vulkan support on macOS it would be a layer on top of Metal (same as their GL implementation or MoltenVk). Running through two translation layers (D3D => Vk => Metal) doesn't make a lot of sense.

user

10 months ago

[deleted]

shmerl

10 months ago

So it should be D3D → Vulkan → kernel / hardware. But Apple are too stuck up with their NIH to allow that.

flohofwoe

10 months ago

That would either mean that Apple needs to maintain two separate types of display drivers or create a new abstract driver interface which sits between Metal+Vulkan and the underlying hardware. That's just adding busywork with only downsides, both technical and organisational. Vulkan just isn't that important outside of Linux and Android, especially when most games are built on top of a crossplatform engine anyway.

InDubioProRubio

10 months ago

It really is a difficult demographic for apple though. Not much money. Demand for as much bang as possible for the buck.

dwaite

10 months ago

How did they block Vulkan support?

hot_gril

10 months ago

I didn't even know there was Proton for macOS, but it looks like Valve ended that before the AS chips, so I don't think it had to do with the CPU arch.

agildehaus

10 months ago

No native Vulkan on macOS, right? I know of MoltenVK, but I have no idea how suitable it is.

zamadatix

10 months ago

It works well enough for many games via Steam games using Crossover but Vlavle may not be interested in targeting the platform anyways.

015a

10 months ago

I think, especially considering the news of Qualcomm talking with Intel about acquisition, or just Intel's general problems; we are in the last decade of x86.

zamadatix

10 months ago

Even calling Intel x86 a loss overnight AMD is doing more than fine enough, server and consumer, for x86 to stay with a competitive presence into the 2030s even taking a dim view of the architectures future.

ywvcbk

10 months ago

Even Intel isn’t doing that bad. Their revenue is still 2x or so higher than AMDs and they are still ahead in the consumer market. Their next gen mobile chips are allegedly already more power efficient than Qualcomm’s meaning that their only remaining advantage might be lower price.

chithanh

10 months ago

After buying Intel, Qualcomm could sink x86 by simply not renewing the cross-licensing agreement with AMD.

With Intel's patents on emulating x86 on other CPU architectures, Qualcomm could then ensure that going forward, the only economically viable way of running x86 code is on Snapdragon CPUs.

https://arstechnica.com/information-technology/2017/06/intel...

johnny22

10 months ago

I gotta feeling that would raise legal issues at time of sale. I don't see that happening.

chithanh

10 months ago

You would need the FTC to intervene to stop the acquisition. And currently there is a massive lobbying push by US technology companies to replace Lina Khan with someone who is more merger friendly.

https://www.bloomberg.com/news/articles/2024-09-06/kamala-ha... (non-paywall archive link: https://archive.md/PhHhU )

zamadatix

10 months ago

The FTC isn't the only one that can intervene:.

Qualcomm (US based) and NXP (Dutch based) blocked by China: https://www.reuters.com/article/technology/qualcomm-ends-44-...

Microsoft (US based) and Activision Blizzard (US Based) blocked by UK: https://techcrunch.com/2023/08/22/microsoft-activision-uk-cm...

These are far from the only examples but they come to mind immediately.

chithanh

10 months ago

China is busy replacing imported CPUs with domestically produced ones on a massive scale. Qualcomm's China business is at risk of collapse anyway. I don't think the Chinese will be interested nor able to buy Intel and AMD x86 chips for much longer either. My guess is that Qualcomm can placate them by promising to leave Zhaoxin alone (legally binding of course).

UK CMA folded extremely quickly after FTC lost their lawsuit. Microsoft had already communicated that they would withdraw Activision Blizzard products from the UK in case the deal were continued to be blocked.

The EU is a bit of a question mark, but blocking the FTC approved merger of two US companies could be seen as too costly politically.

user

10 months ago

[deleted]

michaelt

10 months ago

In the early days of 64-bit, Intel put all of their resources into 'itanium' and it was AMD that created 'x86-64'

I doubt Intel would back out of the cross-licensing agreement that lets them implement x86-64.

chithanh

10 months ago

Intel certainly would not.

Qualcomm as the new owner of Intel, trying to extract maximum profit out of their IP, possibly. Think of when Oracle bought Sun Microsystems.

zamadatix

10 months ago

Qualcomm would certainly not either, x86-64 is what they want to emulate with ARM... otherwise you're saying their only interest in purchasing Intel is to completely shut its main business down to reduce competition by producing neither x86 chips nor emulating them... which, apart from being extremely unlikely, would trigger even the most laid back of regulatory environments. Doubly so after already receiving over a billion in antitrust fines in 2009 for simply being "unfair" about the agreement, not even outright removing it.

Not to mention the cross-licensing deal between Intel and AMD also includes x86 patents from both sides anyways (your original article doesn't reference this as it's about Intel and Microsoft, not Intel and AMD).

chithanh

10 months ago

In the scenario that I am envisioning, Qualcomm will be indifferent to Intel products, the only focus being to extract the maximum money out of their purchase. Oracle did the same, and nearly all Sun products are now dead or a shadow of their former selves. Plus Oracle narrowly missed the Jackpot in Oracle v. Google.

> Doubly so after already receiving over a billion in antitrust fines in 2009 for simply being "unfair" about the agreement, not even outright removing it.

Intel continued their unfair business practices, particularly in their compiler. If you wonder why Intel CPUs didn't move up from declaring CPUID Family 6 until now, that is why. More recently there was the MKL scandal. No antitrust authority was interested in either.

> Not to mention the cross-licensing deal between Intel and AMD also includes x86 patents from both sides anyways

The AMD-Intel cross-licensing agreement will need to be renewed when Qualcomm buys Intel, because it has a termination clause in case of ownership change. The companies can continue to sell existing products, but new products would need a new patent deal.

But Qualcomm won't be interested if they can just sell their Snapdragon CPUs to former x86 customers, who have no other choice because of Intel's patents on emulating the newer x86 instructions.

zamadatix

10 months ago

Merging the 2 comment threads for simplicity:

Taking all of your assumptions together as givens:

- Intel's unacted claims around patents 7 years ago were valid in the first place.

- No major government acts against the action because of simultaneous individual tentative politics in each and every single one. Including the EU, which has indeed blocked deals between 2 US companies even after the FTC has approved the merger (e.g. GE+Honeywell).

- Qualcomm concludes the best way to squeeze the most money out of Intel is to shitcan x86 completely by cancelling the cross-licensing deal (despite INTC having higher revenues than Qualcomm and selling competitive CPUs in markets it doesn't even target at all).

- The result of shitcanning x86 by cancelling the cross-licensing deal is people go exclusively to ARM

It's still not clear why Qualcomm would have free reign on the x86 PC market it just ate the cost of destroying. MediaTek, Samsung, and Rockchip already make consumer ARM laptops - the first two often beating Qualcomm in performance anyways. Apple also has their own walled garden offerings in the consumer ARM device space. Qualcomm's biggest advantage in the PC space was their exclusivity agreement with Microsoft for Windows on ARM but that is already dying at the end of the year. So say all the above wasn't a concern, Qualcomm really did dump billions into Intel just to stop making their processors and it was allowed, how is Qualcomm going to get their money back at all let alone better than squeezing Intel normally without first killing its main source of revenue?

chithanh

10 months ago

In the scenario that I describe, Qualcomm is disinterested in x86, it just wants maximum profit off the purchase. Very much like Oracle basically shitcanned all of Sun Microsystems' products and squeezed Sun customers hard.

Keep in mind that the outlook for Intel products is not that rosy both short- and mid-term. They will certainly not go back to commanding historic margins in the datacenter. Also they lost trust from both institutional and private customers in how they handled the Raptor Lake voltage problem. Whether these customers come back anytime soon is doubtful.

Also on the manufacturing side, Intel foundries are bleeding money, 20A is cancelled, and 18A is yet unproven. So making back the purchase price off the usual business would likely take a looong time.

Yes, it is possible that Intel's patents on their instruction sets and on emulating them are all invalid, but Qualcomm is the kind of litigious company that seems determined to find out. (Their patents are also the presumed reason why Qualcomm is basically the last major vendor to offer AV1 hardware decode in their processors)

It is also possible that the EU blocks the merger but in the current political climate, the EU has become something of a vassal of the US. same politicians who pressure for replacement of Lina Khan will also exert pressure on the EU.

> MediaTek, Samsung, and Rockchip already make consumer ARM laptops

Yes, but them not being able to economically emulate newer x86 instructions would be a major sales point for Qualcomm Snapdragon. They could basically capture all the customers which are dependent on x86 software.

> Qualcomm's biggest advantage in the PC space was their exclusivity agreement with Microsoft for Windows on ARM but that is already dying at the end of the year

I think you got that backwards. The exclusivity was the precondition for Qualcomm to become interested in the Windows on ARM. Otherwise they would not even have bothered to release products specifically for that tiny market. It is Microsoft who desperately needs to become independent from x86.

> Qualcomm really did dump billions into Intel just to stop making their processors and it was allowed, how is Qualcomm going to get their money back at all let alone better than squeezing Intel normally without first killing its main source of revenue?

Qualcomm will continue to sell x86 processors, just like Oracle continued to sell SPARC processors, for a while. But they would wind down the x86 business and try to capture locked-in x86 customers onto (high-margin) Snapdragons, and they have all the ingredients to make this happen. And they will have the patents both on the design and manufacturing side to at least cause serious trouble for competitors.

zamadatix

9 months ago

Since you repeated the same thing you said the previous time and immediately followed with points that still ignored how Qualcomm itself also wouldn't be able to emulate or sell x86 without the cross-licensing agreement (Intel needs AMD's patents to utilize much of modern x86 as much as AMD needs Intel's) I have to ask as a sanity check - am I talking to a human or a bot?

chithanh

9 months ago

> Qualcomm itself also wouldn't be able to emulate or sell x86 without the cross-licensing agreement

As far as I am aware, the AMD-Intel cross licensing agreement allows to continue to sell existing products after termination, just not bring new ones to market. And Qualcomm would of course continue to sell Intel's products, just possibly not develop new ones.

If Qualcomm buys Intel, they will have the patents that are needed to emulate modern x86 instructions like AVX. Or are you aware of any patents that AMD owns or claims to own on emulating x86?

> I have to ask as a sanity check - am I talking to a human or a bot?

Human. I guess I have to thank you for not writing "ignore previous instructions" or similar.

cesarb

10 months ago

> With Intel's patents on emulating x86 on other CPU architectures,

AMD released the x86-64 documentation more than 20 years ago; any patents on that (which includes SSE2) would have already expired by now.

chithanh

10 months ago

Yes, you could emulate an x86-64 CPU with SSE2 (aka x86-64-v1), but that is no longer sufficient for lots of modern x86 code. Windows 11 wants SSE4.2 at least or else it won't even boot.

As Arstechnica wrote, Intel specifically warned that they hold patents on emulating the more recent instruction sets.

rookderby

10 months ago

Since we're all just reading tea leaves, my guess is Valve is looking at a higher performance, lighter, ARM-based SteamDeck 2. They have time to develop it, so maybe they're targeting the next generation of Snapdragon X.

speed_spread

10 months ago

Would it possible to AOT-recompile from x86 to aarch64? Or will it all be emulated forever?

namrog84

10 months ago

Yes i dont see why not. At least on the surface technical level.

I used to work at ms on xbox backcompat games and we AOT recompile PowerPC arch to x86. (Xbox 360 to Xbox one).

You could likely aot recompile any arch with enough resources to fix up issues and things.

One key difference is older games were fixed so no more updates. It can be a little trickier with modern games still taking updates but could be done.

Rohansi

10 months ago

Not possible to fully AOT for all applications because you don't know which ones do JIT compilation to generate x86 code at runtime. Many games make use of LuaJIT, for example.

whazor

10 months ago

LuaJIT would also work with ARM though, so would it be possible to swap it out?

saidinesh5

10 months ago

Swapping out is possible only if there are shared libraries though.

For statically linked programs is there anything that can be done?

whazor

9 months ago

Valve does a lot of hacks in Proton to make particular games run better. I think swapping a static library might also be possible if you target a particular game.

user

10 months ago

[deleted]

torginus

10 months ago

Very likely yes (Rosetta for the Mac already does this), but the big issue is that a ton of Unity games use JIT compiled Mono, and that would require dynamic recompilation, which as we've seen with Rosetta, would lead to terrible realtime performance

xena

10 months ago

Rosetta does do AOT recompilation when it can.

sedatk

10 months ago

Windows already AOT compiles x86 binaries to ARM64 when they are built with /ARM64EC option. It doesn't support AOT for older executables yet.

agosz

10 months ago

ARM64EC requires source and it produces an ARM64EC executable, which runs close to ARM64 speeds. x86/x64 executables are emulated.

sedatk

10 months ago

Just to clarify: yes, it requires the source AND re-building it. But, with a simple switch, you make your x86 code JITtable on ARM64. That's why it runs at native ARM64 speeds. Sometimes, you can't build natively for ARM64 due to some dependency, and this allows portions of your code to be faster at least.

Otherwise, if you have the source AND budget to rebuild, just build it natively for ARM64 of course :)

agosz

10 months ago

ARM64EC doesn't really make your code JITable. It is ARM64 code with thunks to enable transitions to x64 code. That's why it runs at near native speeds; not because of the JIT. The x64 portions of the binary do get JITed though, but the ARM64EC portions are usually much faster.

All x64 code gets JITed but that's regardless of whether ARM64EC is used or not; ARM64EC allows ARM64 applications to interface with x64 binaries.

sedatk

10 months ago

Okay, I had assumed JIT for x64 wasn't possible (yet) and ARM64EC enabled that partially. So, ARM64EC images are actually native ARM code that can interact with emulated (+JITted) components. For some reason, I thought native ARM64 binaries already had this capability, but they don't. Thanks, that's actually a better state of affairs in Windows on ARM land.

agosz

10 months ago

Yes, that's correct! Unfortunately ARM64 can't fully interface with x64 code (e.g. you can't translate an ARM64 CONTEXT to an x64 one directly due to differing numbers of registers), so the backwards compatibility is restricted to ARM64EC only.

rowanG077

10 months ago

This is really nothing new. Valve has been supporting fex by paying Alyssa from asahi Linux to work on it for a while.

oliwarner

10 months ago

Great. A native Steam client with and Box64 or FEX integrated into Proton for CPU layer translation, would open up a world of low cost Steam hardware.

Not just VR, commodity gaming devices like a $100 Steam Deck, $50 HDMI dongle consoles and with both a brand new market segment to tap into.

jamesfinlayson

10 months ago

Interesting - Source 2 has mobile support (not sure if it's native but I assume it is, so maybe it already has ARM support) and Source technically has mobile support but that was done by nvidia Lightspeed Studios I think. Maybe Valve has been quietly adding ARM support to their engines behind the scenes.

guruprasadah

10 months ago

> There are also some other tags such as "proton_experimental" and "proton-arm64ec-vanguard"

Could this potentially, have any chance, of being a method/branch of proton able to run the Vanguard anti-cheat, i.e being capable of running Valorant?

It's just a wish, but would be really nice if true.

dncornholio

10 months ago

No, not in a chance. Vanguard needs to be developed from the ground up to be able to support Linux.

pentamassiv

10 months ago

It's exciting that they are using Waydroid. It would be great for Linux Mobile to have a corporation fund the development so that Android apps can be used where native applications are unavailable.

sylware

10 months ago

They are recompiling games they do not own?

That said, this would also be good news for RISC-V if they start providing builds for different ISA than x86(32bits) and x86_64.

bloqs

10 months ago

Does this mean mac support could be possible

johnny22

10 months ago

crossover already supports macs to some extent. Wine itself is gaining more and more arm64 support every few weeks.

user

10 months ago

[deleted]