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

61–70 of 127 posts

Re: Clip control on the Apple GPU

#61

Post by NobodyNada »

fbanon wrote: post #58
NobodyNada wrote: post #56

Earlier quoted context omitted.

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.

> "Neverball uses legacy “fixed function” OpenGL."

Sure, it'd work for Neverball, but the article is clear that they're looking for a general solution: something that'd work not just for Neverball, but for all OpenGL applications, and would ideally let them give applications control over the clip-control bit through OpenGL/Vulkan extensions.

> 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.

Yes, that was the current state-of-the-art before this article was written:

> As Metal uses the 0/1 clip space, implementing OpenGL on Metal requires emulating the -1/1 clip space by inserting extra instructions into the vertex shader to transform the Z coordinate. Although this emulation adds overhead, it works for ANGLE’s open source implementation of OpenGL ES on Metal.

> Like ANGLE, Apple’s OpenGL driver internally translates to Metal. Because Metal uses the 0 to 1 clip space, it should require this emulation code. Curiously, when we disassemble shaders compiled with their OpenGL implementation, we don’t see any such emulation. That means Apple’s GPU must support -1/1 clip spaces in addition to Metal’s preferred 0/1. The problem is figuring out how to use this other clip space.

Re: Clip control on the Apple GPU

#62

Post by LeifCarrotson »

bri3d wrote: post #48
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…

> Apple does stuff like this so much and gets so little flak for it. Why should they get flak for having internal APIs? The fact that the internal API is a superset of the external API is smart engineering. Think about it this way: Apple could just as well have made the "Metal that Apple uses themselves" some arcane "foocode" IR language or something, as I'm sure many shader compilers and OpenGL runtime implementatio…

> Why should they get flak for having internal APIs? The fact that the internal API is a superset of the external API is smart engineering.

It's not about having good segmentation of user-facing and kernel-side libraries, no one faults them for that.

It's about Apple building user-facing apps that use the whole API, and then demanding that other developers not use the features required to implement those apps because we're not trusted to maintain the look-and-feel, responsiveness, or battery life expectations of apps on the platform.

Re: Clip control on the Apple GPU

#64

Post by Sharlin »

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 also implemented clipping in my software rasterizer a while ago and can definitely sympathize! (Although I've written several simple scanline rasterizers in my life, this was the first time I actually bothered to implement proper clipping. I actually reinvented Sutherland–Hodgman from scratch which was pretty fun.) The problematic part is actually only the near plane due to how projective geometry works. At z=0 there's a discontinuity in real coordinates after z division, which means there can be no edges that cross from negative to positive z. Z division turns such an edge [a0, a1] into an "inverse" edge (-∞, a0'] ∪ [a1', ∞) which naturally makes rendering a bit tricky. In projective/homogenous coordinates, however, it is fine, because the space "wraps around" from positive to negative infinity. All the other planes you can clip against in screen space / NDC space if you wish, but I'm not sure there are good reasons to split the job like that.

Re: Clip control on the Apple GPU

#65

Post by erichocean »

58028641 wrote: post #41
dagmx wrote: post #19

Earlier quoted context omitted.

Because Vulkan, despite the mystical reputation it has in gaming circles, actually has fairly low adoption vs OpenGL . Very few applications in the grand scheme of things use Vulkan, and a minority of games do. Therefore the ROI on supporting OpenGL is very high.

Doesn’t implementing Vulkan give you DirectX with DXVK and VKD3D and OpenGL with Zink for free?

Yes, with appropriate (and reasonably-available) Vulkan extensions.

Re: Clip control on the Apple GPU

#66

Post by dcx »

LeifCarrotson wrote: post #62
bri3d wrote: post #48

Earlier quoted context omitted.

> Apple does stuff like this so much and gets so little flak for it. Why should they get flak for having internal APIs? The fact that the internal API is a superset of the external API is smart engineering. Think about it this way: Apple could just as well have made the "Metal that Apple uses themselves" some arcane "foocode" IR language or something, as I'm sure many shader compilers and OpenGL runtime implementatio…

> Why should they get flak for having internal APIs? The fact that the internal API is a superset of the external API is smart engineering. It's not about having good segmentation of user-facing and kernel-side libraries, no one faults them for that. It's about Apple building user-facing apps that use the whole API, and then demanding that other developers not use the features required to implement those apps because…

But isn't it kind of fair to say that when you look at the case studies presented by (a) the Android app store in the past decade and (b) Windows malware in the decade before that, this trust has in fact not been earned?

I hate a walled garden as much as the next developer, and the median HN reader is probably more than trustworthy. But past performance does predict future performance.

Re: Clip control on the Apple GPU

#67

Post by Cu3PO42 »

58028641 wrote: post #41
dagmx wrote: post #19

Earlier quoted context omitted.

Because Vulkan, despite the mystical reputation it has in gaming circles, actually has fairly low adoption vs OpenGL . Very few applications in the grand scheme of things use Vulkan, and a minority of games do. Therefore the ROI on supporting OpenGL is very high.

Doesn’t implementing Vulkan give you DirectX with DXVK and VKD3D and OpenGL with Zink for free?

Only if you support all of the necessary Vulkan features and extensions. The article states that getting to that point would be a multi-year full time effort, whereas "only" OpenGL seems to be within grasp for this year. And arguably having a lower OpenGL standard soon is better than OpenGL 4.6 in a few years.

Re: Clip control on the Apple GPU

#68

Post by [deleted] »

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…

[deleted]

Re: Clip control on the Apple GPU

#69

Post by rowanG077 »

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…

I mean the signs were clear for basically one and a half years now. It was never a question of if. But a question of when. There were just so many voices that didn't know what they were talking about. Comparing it to nouveau for example.

Re: Clip control on the Apple GPU

#70

Post by smoldesu »

gjsman-1000 wrote: post #10
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…

> pretty insane that OpenGL 2.1 is even functional on a GPU this strange, Well... you were one of the most vocal critics saying it wouldn't happen anytime soon. > unfinished, hacky implementation (the author's own concession) Still more stable than Intel's official Arc drivers, so who defines "hacky"? ;) > Plus, you're going to be stuck on x11 until any serious GPU drivers get written Only because it is running on ma…

> Well... you were one of the most vocal critics saying it wouldn't happen anytime soon.

Yep. Been beating that drum since 2020, looks history proved me right on this one.

> Still more stable than Intel's official Arc drivers, so who defines "hacky"? ;)

Apparently not me, I had no idea that the M1 supported Vulkan and DirectX 12.

Post reply on HN