Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AAA Gaming on Asahi Linux

rosenzweig.io

Post reply on HN
Print view View original

201–210 of 382 posts

Re: AAA Gaming on Asahi Linux

#201

Post by pjmlp »

scheeseman486 wrote: post #189
sweeter wrote: post #123

Earlier quoted context omitted.

A lot of stuff like this shows up, they also have a fork of waydroid and box64. I think a lot of them are projects and a lot of them are just devs with a lot of agency who share the dream

Steam Deck was made possible by their ongoing efforts to enable the play of most of their games catalog on any hardware platform that is computationally capable of running them, regardless of OS or architecture. The end game for Valve isn't Steam Deck 2 or 3 (which is statistically impossible for Valve to produce), but for Steam to be on everything.

Steam Deck was made possible by the plethora of the Windows games developer market and Proton.

Most of the studios that own those games, and target POSIX like OSes on mobile phones and game consoles, are yet to bother with GNU/Linux versions for SteamOS.

Re: AAA Gaming on Asahi Linux

#202

Post by 35mm »

0xDEAFBEAD wrote: post #183
jayd16 wrote: post #145

This makes me think of the classic clip of George Carlin telling a joke about the difference between heaven and hell [1]. Is there a modern equivalent with FAANG, Microsoft, Sony, Valve, etc.? [1] https://www.youtube.com/watch?v=oR8xPC4NEro

In heaven, Microsoft is in charge of gaming, Amazon does the customer service, Apple is responsible for privacy, Facebook does the UI, and everyone works at Google. In hell, Apple is in charge of gaming, Google does the customer service, Facebook is responsible for privacy, Microsoft does the UI, and everyone works at Amazon.

Facebook’s UI is slow as hell.

But otherwise this is accurate.

Re: AAA Gaming on Asahi Linux

#204

Post by dezgeg »

amoss wrote: post #197
y1n0 wrote: post #188

Earlier quoted context omitted.

There are more 4k boundaries than 16k boundaries. The issue is code compiled for 4k boundaries running on a 16k system.

I'm missing something here. Assuming there are pages at 0k, 16k, 32k etc - all of those pages are aligned on 4k boundaries as 4k > 16k. So code written with the assumption that its pages are 4k aligned should have that assumption met when running with 16k pages. It is still early here and I have only had one cup of coffee. Am I misunderstanding something really obvious?

x86 app might mmap 8kb, then munmap the second 4kb and expect that to work. But not possible on 16k pages.

Re: AAA Gaming on Asahi Linux

#205

Post by raffraffraff »

Arcanum-XIII wrote: post #195
0xDEAFBEAD wrote: post #183

Earlier quoted context omitted.

In heaven, Microsoft is in charge of gaming, Amazon does the customer service, Apple is responsible for privacy, Facebook does the UI, and everyone works at Google. In hell, Apple is in charge of gaming, Google does the customer service, Facebook is responsible for privacy, Microsoft does the UI, and everyone works at Amazon.

"Amazon does the customer service" Sure this isn't Hell ? Because customer service at Amazon is a best non existant, at worse actively against you...

Can't you famously just return stuff to Amazon within a month for basically any reason? I purchased a monitor from Dell and after a few weeks it became clear that there was a loose connection internally. It was extremely simple to prove. But getting it replaced was hell. I went through the whole process of creating a ticket, talking to 3 different people, taking photos of the thing from every angle and then after they failed to get back to me for a week, I emailed for an update and was told "Sorry sir, there was no activity on the ticket for over a week so the ticket was closed". It didn't matter that the delay was on their side. And no they wouldn't reopen the ticket, and no I couldn't refer to the old ticket, and no the old photos wouldn't work. Start over. Talk to several different support people again, take all those photos again.

My SIL bought a scanner from Amazon a few months back and never unboxed it because she was moving house. When she did, it was faulty. They took it back without much of a fight even though the month was up. She just said "I unboxed it yesterday, it's broken".

Re: AAA Gaming on Asahi Linux

#206

Post by echelon »

Arcanum-XIII wrote: post #195
0xDEAFBEAD wrote: post #183

Earlier quoted context omitted.

In heaven, Microsoft is in charge of gaming, Amazon does the customer service, Apple is responsible for privacy, Facebook does the UI, and everyone works at Google. In hell, Apple is in charge of gaming, Google does the customer service, Facebook is responsible for privacy, Microsoft does the UI, and everyone works at Amazon.

"Amazon does the customer service" Sure this isn't Hell ? Because customer service at Amazon is a best non existant, at worse actively against you...

Amazon's customer service (for the web store at least) is fantastic.

Even if the core shopping/delivery service fails you, if you complain, they'll take the "customer is always right" position and make you whole. They'll refund or re-ship with no questions asked, without requiring you sending back anything or even so much as providing proof.

I'm sure some people must take advantage of that level of customer service, but it's a really pleasant experience.

Re: AAA Gaming on Asahi Linux

#207

Post by ribit »

Wowfunhappy wrote: post #50

> Tessellation enables games like The Witcher 3 to generate geometry. The M1 has hardware tessellation, but it is too limited for DirectX, Vulkan, or OpenGL. We must instead tessellate with arcane compute shaders > Geometry shaders are an older, cruder method to generate geometry. Like tessellation, the M1 lacks geometry shader hardware so we emulate with compute. Is this potentially a part of why Apple doesn't want…

Apple not supporting Vulkan is a business decision. They wanted a lean and easy to learn API that they can quickly iterate upon, and they want you to optimize for their hardware. Vulkan does not cater to either of these goals.

Interestingly, Apple was on the list of the initial Vulkan backers — but they pulled out at some point before the first version was released. I suppose they saw the API moving in the direction they were not interested in. So far, their strategy has been a mixed bag. They failed to attract substantial developer interest, at the same time they delivered what I consider to be the best general-purpose GPU API around.

Regarding programmable tessellation, Apple's approach is mesh shaders. As far as I am aware, they are the only platform that offers standard mesh shader functionality across all devices.

Re: AAA Gaming on Asahi Linux

#208

Post by chefandy »

raffraffraff wrote: post #205
Arcanum-XIII wrote: post #195

Earlier quoted context omitted.

"Amazon does the customer service" Sure this isn't Hell ? Because customer service at Amazon is a best non existant, at worse actively against you...

Can't you famously just return stuff to Amazon within a month for basically any reason? I purchased a monitor from Dell and after a few weeks it became clear that there was a loose connection internally. It was extremely simple to prove. But getting it replaced was hell. I went through the whole process of creating a ticket, talking to 3 different people, taking photos of the thing from every angle and then after the…

It's changing. I imagine that was always intended to be an introductory thing to cement their position in the marketplace.

Re: AAA Gaming on Asahi Linux

#209

Post by ribit »

miohtama wrote: post #87
VHRanger wrote: post #60

Earlier quoted context omitted.

> Is this potentially a part of why Apple doesn't want to support Vulkan? Because they don't want to implement common Vulkan features in hardware, which leads to less than ideal performance? Yes, it's a big reason. I tried to port the yuzu switch emulator to macos a few years ago, and you end up having to write compute shaders that emulate the geometry shaders to make that work. Even fairly modern games like Mario Od…

Why Apple does not just implement it? They have more resources than anyone in the world. Patents?

Are you talking about Vulkan or about geometry shaders? The later is simple: because geometry shaders are a badly designed feature that sucks on modern GPUs. Apple has designed Metal to only support things that are actually fast. Their solution for geometry generation is mesh shaders, which is a modern and scalable feature that actually works.

If you are talking about Vulkan, that is much more complicated. My guess is that they want to maintain their independence as hardware and software innovator. Hard to do that if you are locked into a design by committee API. Apple has had some bad experience with these things in the past (e.g. they donated OpenCL to Kronos only to see it sabotaged by Nvidia). Also, Apple wanted a lean and easy to learn GPU API for their platform, and Vulkan is neither.

While their stance can be annoying to both developers and users, I think it can be understood at some level. My feelings about Vulkan are mixed at best. I don't think it is a very good API, and I think it makes too many unnessesary compromises. Compare for example the VK_EXT_descriptor_buffer and Apple's argument buffers. Vulkan's approach is extremely convoluted — you are required to query descriptor sizes at runtime and perform manual offset computation. Apple's implementation is just 64-bit handles/pointers and memcpy, extremely lean and immediately understandable to anyone with basic C experience. I understand that Vulkan needs to support different types of hardware where these details can differ. However, I do not understand why they have to penalize developer experience in order to support some crazy hardware with 256-byte data descriptors.

Re: AAA Gaming on Asahi Linux

#210

Post by amoss »

dezgeg wrote: post #204
amoss wrote: post #197

Earlier quoted context omitted.

I'm missing something here. Assuming there are pages at 0k, 16k, 32k etc - all of those pages are aligned on 4k boundaries as 4k > 16k. So code written with the assumption that its pages are 4k aligned should have that assumption met when running with 16k pages. It is still early here and I have only had one cup of coffee. Am I misunderstanding something really obvious?

x86 app might mmap 8kb, then munmap the second 4kb and expect that to work. But not possible on 16k pages.

ah ok, so it would not be pointer alignment inside the pages but instead the assumption that page +4k is a page.
Post reply on HN