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

Clip control on the Apple GPU

rosenzweig.io

Post reply on HN
Print view View original

51–60 of 127 posts

Re: Clip control on the Apple GPU

#51

Post by 58028641 »

rowanG077 wrote: post #50
skrrtww wrote: 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…

Rosetta 2 runs on Linux. There's also FEX.

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

Re: Clip control on the Apple GPU

#52

Post by chaxor »

bla3 wrote: 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…

This is why the Asahi Linux project is so exciting!! You get the great performance at low-power (M* ARM processors) while still getting the more performant and useful Linux experience.

I am really thankful to the Asahi Linux team, and specifically in this instance for the GPU, [Alyssa Rosenweig](https://github.com/alyssarosenzweig), [Asahi Lina](https://github.com/asahilina), and [Doug all Johnson](https://github.com/dougallj).

Re: Clip control on the Apple GPU

#53

Post by 3836293648 »

Miraste wrote: post #14
smoldesu wrote: post #6

Earlier quoted context omitted.

It's pretty insane that OpenGL 2.1 is even functional on a GPU this strange, but remember; this is still an unfinished, hacky implementation (the author's own concession). Plus, you're going to be stuck on x11 until any serious GPU drivers get written, which in many people's opinion is just as bad as no hardware acceleration at all. No MacOS-like trackpad gestures either, you'll be waiting for Wayland support to get…

Why would you need Wayland for trackpad gestures?

You technicay don't, but the implementations on X are kinda terrible and can't do 1:1

Re: Clip control on the Apple GPU

#54

Post by skrrtww »

rowanG077 wrote: post #50
skrrtww wrote: 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…

Rosetta 2 runs on Linux. There's also FEX.

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, looks interesting.

Re: Clip control on the Apple GPU

#55

Post by bob1029 »

bpye wrote: post #34
Jasper_ wrote: post #30

Earlier quoted context omitted.

Vertex/triangle clipping is quite rare, and mostly used for clipping against the near plane (hopefully rare in practice). Most other implementations use a guard band as a fast path (aka doing it in screen space) -- real clipping is only used where your guard band doesn't cover you, precision issues mostly. I'm not sure what issues you're hitting, but I've never found clipping to be that challenging or difficult. Also…

Even with a guard band don’t you need to at least test the polygons for Z clipping prior to the perspective divide? Clipping in X and Y is simpler at least, and again the guard band hopefully mostly covers you.

> Even with a guard band don’t you need to at least test the polygons for Z clipping prior to the perspective divide?

Yes. Guard band is an optimization that reduces the amount of potential clipping required. You still need to be able to clip for fundamental correctness.

If you totally reject a vertex for a triangle without determining precisely where it intersects the desired planes, you are effectively rejecting the entire triangle and creating yucky visual artifacts.

Re: Clip control on the Apple GPU

#56

Post by NobodyNada »

fbanon wrote: post #47

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

What projection matrix?

Remember that this translation needs to happen at the graphics driver level. For fixed-function OpenGL where the application actually passes the graphics driver a projection matrix this would be doable. But if your application is using a version of OpenGL newer than 2004, the projection matrix is a part of your vertex shader. The graphics driver can't tell what part of your shader deals with projection, and definitely can't tell what uniforms it would need to tweak to modify the projection matrix -- many shaders might not even have a projection matrix.

Re: Clip control on the Apple GPU

#57

Post by argsnd »

alberth wrote: post #26
pornel wrote: post #12

Apple could help by documenting this stuff. I remember the good old days when every Mac OS X came with an extra CD with Xcode, and Apple was regularly publishing Technical Notes detailing implementation details. Today the same level of detail is treated as top secret, and it seems that Apple doesn't want developers to even think beyond the surface of the tiny App Store sandbox.

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

I mean that thread is looking at pre-release software

Re: Clip control on the Apple GPU

#58

Post by fbanon »

NobodyNada wrote: post #56
fbanon wrote: post #47

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

What projection matrix? Remember that this translation needs to happen at the graphics driver level. For fixed-function OpenGL where the application actually passes the graphics driver a projection matrix this would be doable. But if your application is using a version of OpenGL newer than 2004, the projection matrix is a part of your vertex shader. The graphics driver can't tell what part of your shader deals with p…

I know. But the second sentence of the article starts with:

"Neverball uses legacy “fixed function” OpenGL."

But also you could simply remap the Z coordinate of gl_Position at the end of the vertex stage, do the clipping in [0,1] range, then map it back to [-1,1] for gl_FragCoord at the start of the fragment stage.

Re: Clip control on the Apple GPU

#59

Post by nauful »

bob1029 wrote: post #25

Clip space is the bane of my existence. I've been building a software rasterizer from scratch and implementing vertex/triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide. It still staggers me that there is not 1 coherent reference for how to do all…

You have to clip against planes in 4D space (xyzw) before perspective divide (xyz /= w), not 3D (xyz).

This simplified sample shows Sutherland-Hodgman with 4D clipping: https://web.archive.org/web/20040713023730/http://wwwx.cs.un... The main difference is the intersect method finds the intersection of a 4D line segment against a 4D plane.

Re: Clip control on the Apple GPU

#60

Post by ianlevesque »

argsnd wrote: post #57
alberth wrote: 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

I mean that thread is looking at pre-release software

There is software that approaches barely functional after dozens of rounds of QA testing, and then there is software that is implemented on a solid foundation with care and happens to have a few bugs. Unfortunately that many bugs in a beta implies the former. I think the thread comes from a disappointment that Apple is moving from the second category to the first.
Post reply on HN