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

21–30 of 127 posts

Re: Clip control on the Apple GPU

#21

Post by phire »

gjsman-1000 wrote: post #8
chongli wrote: post #7

Earlier quoted context omitted.

Apple has a very complicated Display Controller design Can anyone in the know give more information here? Why would Apple want to do this? What could they be doing that's so complicated in the display controller?

https://twitter.com/marcan42/status/1549672494210113536 and https://twitter.com/marcan42/status/1415360411260493826?lang... and https://twitter.com/marcan42/status/1526104383519350785 As to why? Well, if it ain't broke don't fix it from iPhone, but it is still a bit of a mystery. In a nutshell from those threads: 1. Apple's DCP silicon layout is actually massive, explaining the 1 external display limit 2. Apple imple…

The complexity with the firmware split across the main CPU and a coprocessor seems to be a historical artefact.

Seems the DCP driver was originally all on the main CPU, and when apple got these cheap coprocessor cores, they took a lazy approach of just inserting a simple RPC layer in the middle. The complexity for Asahi comes from the fact that it's a c++ API that can change very dynamically from version to version.

And yes, these ARM coprocessor cores are cheap, apple have put at least 16 of them [1] on the M1, on top the 4 performance and 4 efficiency cores. They are an apple custom design that implement only the 64bit parts of the ARMv8 spec. I'm not entirely sure why the actual DCP is so big, but it's not because of the complex firmware. Potentially because the DCP includes enough dedicated RAM to store an entire framebuffer on-chip.

If so, they will be doing this because it allows for lower power consumption. The main DRAM could be put in a power-saving mode and kept there for seconds or even minutes at a time without having to wake it up multiple times per frame, even when just showing a static image.

[1] https://twitter.com/marcan42/status/1557242428876537856

Re: Clip control on the Apple GPU

#22

Post by fezfight »

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…

If you buy a hackintosh, you have to sometimes mess around to get stuff to work. Same goes for Linux on random hardware. If you check first and buy a machine that supports the OS you're using, you don't have to do anything special. It'll work as you expect.

It's freeing not to be beholden to the likes of someone like Tim Cook who, it would seem, spends the majority of his waking hours figuring out how to hide anticonsumer decisions under rugs.

Re: Clip control on the Apple GPU

#23

Post by throwaway08642 »

phire wrote: post #21
gjsman-1000 wrote: post #8

Earlier quoted context omitted.

https://twitter.com/marcan42/status/1549672494210113536 and https://twitter.com/marcan42/status/1415360411260493826?lang... and https://twitter.com/marcan42/status/1526104383519350785 As to why? Well, if it ain't broke don't fix it from iPhone, but it is still a bit of a mystery. In a nutshell from those threads: 1. Apple's DCP silicon layout is actually massive, explaining the 1 external display limit 2. Apple imple…

The complexity with the firmware split across the main CPU and a coprocessor seems to be a historical artefact. Seems the DCP driver was originally all on the main CPU, and when apple got these cheap coprocessor cores, they took a lazy approach of just inserting a simple RPC layer in the middle. The complexity for Asahi comes from the fact that it's a c++ API that can change very dynamically from version to version.…

@marcan42 said that on the M1 MacBook Pro models, the DCP also implements hardware-level antialiasing for the notch and rounded display corners.

Re: Clip control on the Apple GPU

#24

Post by Pulcinella »

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.

It would be one thing if the private APIs were limited to system frameworks and features while Apple’s own apps weren’t allowed to use them, but they do. E.g. The Swift Playgrounds app for iPad is allowed to share and compile code, run separate processes, etc. which isn’t normally allowed in the AppStore. They also use blur and other graphical effects (outside of the background blur material and the SwiftUI blur modifier) that are unavailable outside of private APIs.

It stinks because of the perceived hypocrisy and the inability to compete on a level playing field or leave the AppStore (and I say this as someone who normally doesn’t mind the walled garden!)

Re: Clip control on the Apple GPU

#25

Post by bob1029 »

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 of this. Virtually every reference about clipping winds up with something like "and then the GPU waves its magic wand and everything is properly clipped & interpolated :D". Every paper I read has some "your real answer is in another paper" meme going on. I've got printouts of Blinn & Newell, Sutherland & Hodgman, et. al. littered all over my house right now. About 4 decades worth of materials.

Anyone who works on the internals of OGL or the GPU stack itself has the utmost respect from me. I cannot imagine working in that space full-time. About 3 hours of this per weekend is about all my brain can handle.

Re: Clip control on the Apple GPU

#26

Post by alberth »

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

Re: Clip control on the Apple GPU

#27

Post by samstave »

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…

Be the documentation you want to see in the world.

Re: Clip control on the Apple GPU

#28

Post by skrrtww »

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

[1] https://box86.org

Re: Clip control on the Apple GPU

#29

Post by Jasper_ »

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…

As a graphics engineer, good riddens to the old clip space, 0...1 really is the correct option. We also don't know what else "OpenGL mode" enables, and the details of what it does probably changes between GPU revisions -- the emulation stack probably has the details, and changes its own behavior of what's in hardware and what's emulated in the OpenGL stack depending on the GPU revision.

Also, to Alyssa, if she's reading this: you're just going to have to implement support shader variants. Build your infrastructure for supporting them now. It's going to be far more helpful than just for clip control.

But yes, the Vulkan extension was just poorly specified, allowing you to change clip spaces between draws in the same render pass is, again, ludicrous, and the extension should just be renamed VK_EXT_i_hate_tilers (like so many others of their kind). Every app is going to set it at app init and forget it; the implementation using the render pass bit and flushing on change will cover the 100% case, and won't be slow at all.

Re: Clip control on the Apple GPU

#30

Post by Jasper_ »

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, clip control and clip space aren't really specifically about clipping -- clip space is just the output space of your vertex shader, and the standard "clip control" extension just controls whether the near plane is at 0 or -1. And 0 is the correct option.

Post reply on HN