I'm excited for the day that I can easily install SteamOS (the modern one that runs on the Steamdeck) on an M2 Mac mini for an insanely powered "Steam console" for my living room TV.
I don't really get the V-Tuber thing (other than wanting to stay anonymous) but having code explained to me by an anime character is hilarious.
I honestly find it very hard to take someone seriously who chooses this kind of persona, even though it's hard to argue with their technical ability and results.
He's been clear that he's not Asahi Lina... and he's also not a GPU hacker as far as I know.
He even did a super-cringe "take over" video, where Asahi Lina "broke into" one of streams: https://www.youtube.com/watch?v=effHrj0qmwk
Probably some pre-recorded, agreed upon advertisement to promote a new channel.
I have no specific knowledge, but it seems very clear to me that at the very least marcan is a collaborator in the persona of Asahi Lina; and absent further contrary evidence, them being the same makes sense.
—⁂—
¹ And if stream key exfiltration actually happened, I find it hard to imagine anything but acrimony arising.
> If you want to support my work, you can donate to marcan’s Asahi Linux support fund on GitHub Sponsors or Patreon, which helps me out too!
I'm not really willing to indulge the greater discussion, but marcan has done some serious GPU hacking before, reverse engineering the microcode (not shaders) of the PS4's GPU to fix bugs that the PS4 hacked around in the drivers.
You cannot be this gullible. "Asahi Lina" is a pseudonym for Marcan.
/home/marcan and /home/lina on the same box.
He/she is quite the creative person I must say.
Things are certainly looking better than they did a couple years ago, but getting ARM to run x86 code faster-than-native is an uphill battle. Maybe even an impossible one, but I've been surprised before (like with DXVK).
[0] Crysis on a Rockchip ARM SOC, for example: https://youtu.be/k6C5mZvanFU?t=1069
Not having any experience in that industry, I wonder what the driving forces of this are. I suspect it's some combination of incredibly brittle codebases that cease to build if glanced at the wrong way and aversion to spending anything on games post-release.
I am pretty sure that is the answer. Unless the game is Cyberpunk levels of unplayable, there is no money in post release support unless it is bundled with DLC or GOTY releases.
Back in the day it was pretty commonly sited figure that like 90% of a game's revenue came in the first 3-4 weeks of release. DLC and "seasons" are an attempt to stretch it out and make more off a single release, but I haven't heard how well that works.
That also dates back to back in the days, we just called it expansion packs.
The primary reason is that there's no money in it. Like movies, your "one shot" game (without some sort of continuous billing e.g. mmo, subscription, continuous stream of DLCs) makes most of its revenue in the first few weeks, and once the kinks are ironed out what it makes afterwards doesn't really depend on maintenance.
Additional maintenance doesn't pay for itself, the producer doesn't pay the devs for that, and thus the devs take on the next contract to pay the bills. Not to mention additional maintenance is a risk.
- Total dependency on an engine's build system
- Lack of official support for uncommon platforms
- Extremely low expected ROI even if it were possible to deliver on other platforms
Gamedevs aren't in the business of building platforms, they're in the business (mostly) of consuming them and going where the players are.
Gamedevs not updating is because
- The engines themselves are indeed outrageously brittle at times, with LTS releases sometimes containing significant bugs that persist against newer releases of minor and major versions
- New releases can actually cause dramatic regressions, not just in terms of bugs, but in terms of features, stability, binary size, and more
- AAAs are wasting time chasing the next big thing, non-AAAs are struggling with few people and need to constantly be building the next thing because they're building products, not services
- Gamedevs are largely media/entertainment companies, very few act like technology companies
An example that come to mind immediately is how much of a mess it is to get games that were built with Games for Windows Live like the PC port of Fable 3 running on modern Windows. It's possible, but there's a ridiculous number of hoops to jump through, none of which would be necessary if Microsoft shipped a quick and dirty update that pulled out the Games for Windows Live dependency.
I'm pretty sure it's just vanilla ARM NEON so I don't think it will take any reverse engineering. The Apple Silicon GPU is custom, but the CPU is just minor extensions to (and compatible with) AArch64. Rumour has it that this is because AArch64 was designed by Apple and donated to ARM (who Apple has close relationship with being that they were a founding member).
...it also raises the question of how emulated titles fare against translated ones. It would be fascinating to see how something like Dark Souls Remastered performs through Yuzu vs DXVK on Apple Silicon.
though amx won’t help out with emulation much
Then I guess Metal on Mac can't be such a big issue either.
Wine FAQ concludes
> "Wine is not just an emulator" is more accurate. Thinking of Wine as just an emulator is really forgetting about the other things it is. Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.
Wine (written as WinE when I first encountered it, IIRC) emulates the Windows runtime environment.
On macOS, IIRC the userspace and kernel-space page size can be different and different userspace programs can run with diferent page sizes, however on Linux the page size is currently fixed across the system and set at compile time. The M1's IOMMU only supports 16k-aligned pages, so memory regions that need to be shared with other hardware (e.g. the GPU) need to be 16k-aligned. As such (and because Linux doesn't currently have great support for mixed page sizes), the Asahi Linux project has decided to run with 16k pages globally. However, that breaks a number of applications that are expecting 4k pages.
More info: https://github.com/AsahiLinux/docs/wiki/Broken-Software
I think that Fedora may be leading the pack here, see https://danielpocock.com/power9-aarch64-64k-page-sizes/
That means a lot of software has come to assume that.
Certain memory buffers need to be page size aligned, or a multiple of pages long. Code can only be loaded to a page aligned memory address. Memory mapping and read/write/execute permissions can only be set on a per-page basis.
If all that stuff is hardcoded now, there will be lots of fixes necessary to make things work properly with a different page size.
And those fixes probably will need the software to be recompiled. And some software is only distributed in binary form, and getting someone to recompile it may be nearly impossible.