Live data from Hacker News

Clip control on the Apple GPU

rosenzweig.io

91–100 of 127 posts

Re: Clip control on the Apple GPU

#91
post #90
post #3

> Here’s a little secret: there are two graphics APIs called “Metal”. There’s the Metal you know, a limited API that Apple documents for App Store developers, an API that lacks useful features supported by OpenGL and Vulkan. > And there’s the Metal that Apple uses themselves, an internal API adding back features that Apple doesn’t want you using. Apple does stuff like this so much and gets so little flak for it. I us…

[deleted]

[deleted]

Re: Clip control on the Apple GPU

#92
post #83
post #54

Earlier quoted context omitted.

I guess that's true, I forgot about Apple making Rosetta 2 installable in Linux VMs. Also though, since Rosetta 2 was released, it's had an incredibly slow implementation of x87 FPU operations, and anything that relies on x87 floating point math (including lots of games) is currently running about 100x slower than it ought to. Apple is aware of it but it's still not fixed in Ventura. I hadn't heard of FEX before, loo…

Huh, I thought everyone used SSE floats these days. I suppose there may be old games compiled with x87 floats, but I'd expect those to be made for CPUs so old that even slow x87 emulation wouldn't be a big issue. What software do people have x87-related issues with?

The software I personally have the most issues with is Star Wars Episode 1: Racer, a 3d title from 1999 that from what I understand uses x87 math extensively. In Parallels (i.e. no Rosetta) it runs at 120fps easily, while in CrossOver the frame rate barely ekes above 20. Old titles like Half-Life, all other Source games, Fallout 3, SWTOR etc. all run vastly worse than they should, and many cannot run at playable framerates through Rosetta. Honestly, the problem most likely extends to more of Rosetta's floating point math than just x87.

The author of REAPER has also written about it some: https://user.cockos.com/~deadbeef/index.php?article=842

There's been lots of discussion about the issue in the Codeweavers forums, and Codeweavers points the blame squarely at Apple, who have been, predictably, very quiet about it.

Re: Clip control on the Apple GPU

#94
post #47

Couldn't you just pre-multiply the projection matrix to remap the Z range from [-1,1] to [0,1]?

This is effectively what the vertex shader modification would do -- the same trick that ANGLE does: gl_Position.z = (gl_Position.z + gl_Position.w) * 0.5;

This is the same as modifying a projection matrix -- you're doing the same post-multiply to the same column. But note that there's no guarantee there's ever a projection matrix. Clip space coordinates could be generated directly in the vertex shader.

Re: Clip control on the Apple GPU

#95
post #81

I don't know why there's so much love for OpenGL in the communities still. Maybe it's the "open" part in the name, which was always confusing people, thinking it's an open source standard or something like that. The API is very antiquated, doesn't match modern GPU architectures at all and requires many workarounds in the driver to get the expected functionality, often coming at a performance cost. Vulkan is nice, but…

You acknowledge that Vulkan is too low level for people who aren't investing billions into an AAA graphics engine. And you surely know that OpenGL and Vulkan are the only two cross-platform graphics APIs. Are you sure you can't infer why people like OpenGL from those two points? Especially in Linux-heavy communities where DX and Metal aren't even options? I assure you, none of the "love" for OpenGL comes from the ele…

There should be more effort to support Direct3D under Linux. We have Wine and DXVK, but it should be easier to integrate the D3D support into Linux applications.

Re: Clip control on the Apple GPU

#96

Earlier quoted context omitted.

Does Rosetta on Linux support 32 bit code? I believe FEX does.

Rosetta supports emulating 32-bit code.

On Linux? I know it has been confirmed on macOS. I haven’t heard anyone say they ran 32 bit code on Linux.

Re: Clip control on the Apple GPU

#97
post #93

Can you run a PCIE enclosure over thunderbolt on asahi Linux yet? Could this enable GPUs that already work on aarch64 Linux?

I would assume all linux GPU drivers would need to be adapted at least a little to support the larger page size (most linux AARCH64 kernel level code is writing assuming 4kb pages).

Re: Clip control on the Apple GPU

#98
post #79
post #26

Earlier quoted context omitted.

I really wish Apple would do another "Snow Leopard" - go an entire year WITHOUT any new features and just fix bugs and documentation. This twitter thread is a perfect example of why it's needed https://twitter.com/nikitonsky/status/1557357661171204098

Snow Leopard had few user-facing features, but it did have new APIs, such as Grand Central Dispatch and OpenCL, and also an optional 64-bit kernel. https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard

OpenCL is not an OS level API. I guarantee you they were basically just redistributing Intel and NVidia implementations. GCD isn't OS level either, it's just a library, but it is at least a new API.

Re: Clip control on the Apple GPU

#100
post #28

Despite the progress here, for me it raises a question: Most of the old games she mentions are x86 32bit games. What's the story for how these programs are actually going to run in Asahi? Box86 [1] doesn't sound like it's projected to run on M1. Rosetta 2 on macOS allows 32-bit code to be run by a 64-bit process, which is the workaround CrossOver et. al. use (from what I understand), but that obviously won't be avail…

QEMU has a “user mode” feature where it can transparently emulate a Linux process and translates syscalls. You can probably run at least old 32-bit Linux games that way, assuming you have appropriate userland libraries available. Windows content might be trickier.
Post reply on HN