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

81–90 of 127 posts

Re: Clip control on the Apple GPU

#81

Post by mort96 »

skocznymroczny wrote: post #74

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 elegance of its design.

Re: Clip control on the Apple GPU

#82

Post by Sharlin »

Jasper_ wrote: post #30
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…

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…

Guard band clipping is only really applicable to "edge function" type rasterizers. For the classic scanline-based algorithm, sure, you can easily clip to the right and bottom edges of the viewport while rasterizing, but the top and left edges are trickier. Clipping in clip space, before rasterization, is more straightforward, given that you have to frustum cull primitives anyway.

Re: Clip control on the Apple GPU

#83

Post by mort96 »

skrrtww wrote: post #54
rowanG077 wrote: post #50

Earlier quoted context omitted.

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, 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?

Re: Clip control on the Apple GPU

#84

Post by Sharlin »

Jasper_ wrote: post #43
bob1029 wrote: post #32

Earlier quoted context omitted.

> clipping against the near plane (hopefully rare in practice) I am not sure I understand why this would be rare. If I am intending to construct a rasterizer for a first-person shooter, clipping is essentially mandatory for all but the most trivial of camera arrangements.

Yes, of course, I was definitely imagining you were struggling to get simpler scenes to work. But also, proportionally few of your triangles in any given scene should be near-plane clipped. It's OK to have a slow path for it, and then speed it up later. I've never felt the math for the adjusted barycentrics is too hard, but it can take a bit to wrap your head around. Good luck :)

You and the GP have different rasterization algorithms in mind I think. The GP, I presume, is talking about a classic scanline-based rasterizer rather than an edge function "am I inside or not" type rasterizer that GPUs use.

Re: Clip control on the Apple GPU

#85

Post by madeofpalk »

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

Ahh yes, that "just fix bugs" release that would delete your main user account if you used a guest user https://www.engadget.com/2009-10-12-snow-leopard-guest-accou...

Besides, rebuilding/redesigning the settings screen is a perfect "snow leopard" thing. That's not an actual Feature.

The problem isn't doing features, the probably is doing a bad job.

Re: Clip control on the Apple GPU

#86

Post by bob1029 »

royjacobs wrote: post #73
bpye wrote: post #36

Earlier quoted context omitted.

Clipping or culling? I expect it’s mostly the latter unless your camera ends up intersecting the geometry.

As an example, if you're writing a shooter then the floor might be a large square that will almost definitely be intersecting the near plane. You absolutely need clipping here.

This is precisely the first place I realized I needed proper clipping. Wasted many hours trying to hack my way out of doing it the right way.

Re: Clip control on the Apple GPU

#87

Post by viraptor »

smoldesu wrote: post #6
gjsman-1000 wrote: post #2

Optimistic that OpenGL 2.1 will be available by the end of the year on Asahi - well that is news. It's only 2.1, but that's enough (as stated) for a web browser, desktop acceleration, and old games. Also RIP all the countless pessimistic "engineers" here and elsewhere saying we'd be waiting for years more for any graphics acceleration. Edit: It is true though that AAA Gaming will wait: "Please temper your expectation…

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…

> if you could get DOS titles like Diablo 2

Did you mean some other title? Even diablo 1 was a Windows game.

Re: Clip control on the Apple GPU

#88

Post by joakleaf »

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…

Not sure if you got through clipping, but it was one of those things I had to go through first at some point in the mid 90s myself. I feel your pain, but after having implemented it about 5-10 times in various situations, variants and languages, I can promise it gets a lot easier.

In my experience it is most elegant to clip against the 6 planes of the view-frustrum in succession (one plane at a time). Preferably clipping against the near-plane first, as that reduces the set of triangles the most for subsequent clips.

Your triangles can turn into convex polygons after a clip. So it is convenient to start with a generic convex polygon vs. plane-clipping algorithm; The thing to be careful about here is that points can (and will) lie on the plane.

Use the plane equation (f(x,y,z)=ax+by+cz+d) to determine if a point is on one side, on the plane, or the other side.

It is convenient to use a "mask" to designate the side a point v=(x,y,z) is on. So: 1 := inside_plane (f(x,y,z)>eps) 2 := outside_plane (f(x,y,z)=eps && f(x,y,z)When you go through each edge of the convex polygon (v_i->v_{i+1}), you can check if you should clip the edge using the mask. I.e.:

if (m(v_i)&m(v_{i+1})==0 the points are on opposite side => clip [determine intersection point].

Since you are just clipping to the frustrum, just return a list of the points that are inside or on the plane (i.e. m(v_i)&1==1) and the added intersection points.

There are lots of potential for optimization, of course, but I wouldn't worry about that. There are lots of other places to optimize a software rasterizer with more potential, in my experience.

Re: Clip control on the Apple GPU

#89

Post by fabiensanglard »

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…

I wrote about this a few years ago (https://fabiensanglard.net/polygon_codec/index.php).

It was a pain to lean indeed and the best resources were quite old:

- "CLIPPING USING HOMOGENEOUS COORDINATES" by James F. Blinn and Martin E. Newell

- A Trip Down the Graphics Pipeline by Jim Blinn (yes the same Blinn that co-authored the paper above).

Re: Clip control on the Apple GPU

#90

Post by [deleted] »

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…

[deleted]
Post reply on HN