Valve is testing ARM64 support for popular games
notebookcheck.net
notebookcheck.net
Compatibility with your existing Steam library out of the box will be a huge competitive advantage for Deckard over Meta Quest.
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.
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.
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.
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.
https://www.bloomberg.com/news/articles/2023-11-09/new-steam... (archived link w/o paywall: https://archive.md/VWvsW )
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.
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.
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.
Please give us 30% of Steam. Tnx.
Now, post-ARM, it's beat by Linux even.
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!
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.
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.
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.
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.
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.
Is Proton in some way inferior to native?
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.
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.
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.
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"?
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.
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.
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.
> 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?
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.
(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)
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.
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).
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.
As for the missing libraries, if you can fetch some old Debian DVD images (just the first DVD) it will run fine.
it is not full Proton, but DXVK is used on Windows as it has sometimes better compatibility and/or performance for older titles.
Soon Wine will have Wayland support and 99% of those ports that no one is willing to update will remain stuck on X11.
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.
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) .
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.
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.
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.
> 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.
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.
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.
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?
It would work by placing carrots and whips in place for anyone that wants to target their shop, just like console vendors do.
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.
Every Counter-Strike, every Team Fortress, every Half-Life (even Alyx), every Portal, DOTA 2, Artifact.
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.
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.
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.
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.
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.
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.
I don't have high hopes however.
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.
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.
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.
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.
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...
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).
What do you mean by that?
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.
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.
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.
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.
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.
Current Macs and iOS devices are powerful enough. There's a handful of developers shipping full current-gen games to both platforms.
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.
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.
Any game engine worth using has Metal support for ages.
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.
> 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.
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.
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.
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.
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.
Sorry for the rant, I also hate bad UX. It makes me feel stupid for no good reason.
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...
https://www.bloomberg.com/news/articles/2024-09-06/kamala-ha... (non-paywall archive link: https://archive.md/PhHhU )
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.
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.
I doubt Intel would back out of the cross-licensing agreement that lets them implement x86-64.
Qualcomm as the new owner of Intel, trying to extract maximum profit out of their IP, possibly. Think of when Oracle bought Sun Microsystems.
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).
> 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.
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?
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.
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.
AMD released the x86-64 documentation more than 20 years ago; any patents on that (which includes SSE2) would have already expired by now.
As Arstechnica wrote, Intel specifically warned that they hold patents on emulating the more recent instruction sets.
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.
For statically linked programs is there anything that can be done?
Otherwise, if you have the source AND budget to rebuild, just build it natively for ARM64 of course :)
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.
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.
[0] https://steamdb.info/app/3043620/history/?changeid=25321568
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.
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.