Live data from Hacker News

Clip control on the Apple GPU

rosenzweig.io

71–80 of 127 posts

Re: Clip control on the Apple GPU

#71
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…

Unfortunately such a behavior is not at all new.

The best known example of these methods is how Microsoft has exploited the replacement of MS-DOS with Windows 3.0 and especially with Windows 95.

During the MS-DOS years, the only Microsoft software products that were successful were their software development tools, i.e. compilers and interpreters, and even those had strong competition, mainly from Borland. Those MS products addressed only a small market and they could not provide large revenues. The most successful software products for MS-DOS were from many other companies.

That changed abruptly with the transition to various Windows versions, when the Microsoft developers started to have a huge advantage over those from any other company, both by being able to use undocumented internal APIs provided by the MS operating systems and also by knowing in advance the future documented APIs, before they were revealed to competitors.

Thus in a few years MS Office has transitioned from an irrelevant product, much inferior to the competition, to the dominant suite of office programs, which has eliminated all competitors and which has become the main source of revenue for MS.

Re: Clip control on the Apple GPU

#72
post #57

Earlier quoted context omitted.

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.

But it is not even a "Consumer Beta" it is a developer beta- for catching bugs and allowing devs to create applications for new APIs while Apple polishes the build for release? Was snow leopard ever released as a dev beta even?

Re: Clip control on the Apple GPU

#73
post #36
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.

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.

Re: Clip control on the Apple GPU

#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 it goes into the other extreme. It's very low level and designed for advanced users. Even getting anything on the screen in Vulkan is intimidating because you have to write everything from scratch. To go beyond hello world, you even have to write your own memory allocator (or use an existing opensource one) because you can only do a limited amount of memory allocations and you're expected to allocate a huge block of memory and suballocate it as needed by your application.

In comparison, DX12 is a bit easier to grasp. It has some nice abstractions such as commited resources, which take some of the pain away.

Personally I like Metal as an API. It is lower level than OpenGL, getting rid of most nasty OpenGL things (state machine, lack of pipeline state objects), yet it is very approachable and easy to transition to from DX11/OpenGL. I was happy when I saw WebGPU was based on Metal at first. WebGPU is my go-to 3D API at the moment, especially with projects like wgpu-native which make it usable on native platforms too (don't let the Web in WebGPU confuse you).

Re: Clip control on the Apple GPU

#76

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…

> Vulkan is nice, but it goes into the other extreme. It's very low level and designed for advanced users. Even getting anything on the screen in Vulkan is intimidating because you have to write everything from scratch.

I honestly believe that this is the major reason. Developing a hobby project with OpenGL is little more than using SDL or GLFW to get a window with a GLContext and then you can just start calling commands. Vulkan is much more complicated and unless you're really pushing performance limits, you're not getting much of a benefit for the extra headache.

Re: Clip control on the Apple GPU

#77
post #29
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 read…

>good riddens to the old clip space, 0...1 really is the correct option

More like 1...0, which nicely improves depth precision. Annoyingly due to symmetric -1...1 range reverse-Z cannot be used on OpenGL out of the box, but it can be fixed with ARB_clip_control. https://developer.nvidia.com/content/depth-precision-visuali...

Re: Clip control on the Apple GPU

#78

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…

> Vulkan is nice, but it goes into the other extreme. It's very low level and designed for advanced users. Even getting anything on the screen in Vulkan is intimidating because you have to write everything from scratch. I honestly believe that this is the major reason. Developing a hobby project with OpenGL is little more than using SDL or GLFW to get a window with a GLContext and then you can just start calling comm…

OpenGL is what you use if you just want to render some triangles on the GPU with a minimum of hassle on the most platforms (which is quite a few if you include GLES, WebGL, and ANGLE). Most people aren't writing graphics engines for AAA games so OpenGL is all they need.

Re: Clip control on the Apple GPU

#79
post #26
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

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

Re: Clip control on the Apple GPU

#80
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 it? Or does Rosetta 2 run on Mac OS with a Linux shim to ask the host to kindly Rosetta-ify a given binary?
Post reply on HN