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

An appeal to Apple from Anukari

anukari.com

Post reply on HN
Print view View original

21–30 of 197 posts

Re: An appeal to Apple from Anukari

#21

Post by charcircuit »

>Any MTLCommandQueue managed by an Audio Workgroup thread could be treated as real-time and the GPU clock could be adjusted accordingly.

>The Metal API could simply provide an option on MTLCommandQueue to indicate that it is real-time sensitive, and the clock for the GPU chiplet handling that queue could be adjusted accordingly.

Realtime scheduling on a GPU and what the GPU is clocked to are separate concepts. From the article it sounds like the issue is with the clock speeds and not how the work is being scheduled. It sounds like you need something else for providing a hint for requesting a higher GPU clock.

Re: An appeal to Apple from Anukari

#22

Post by mensetmanusman »

Dlemo wrote: post #16
humbledrone wrote: post #2

Some folks may have seen my Show HN post for Anukari here: https://news.ycombinator.com/item?id=43873074 In that thread, the topic of macOS performance came up there. Basically Anukari works great for most people on Apple silicon, including base-model M1 hardware. I've done all my testing on a base M1 and it works wonderfully. The hardware is incredible. But to make it work, I had to implement an unholy abomination o…

[flagged]

It’s technical to over half of programmers who don’t need to know these types of details about hw/sw interactions.

Re: An appeal to Apple from Anukari

#23

Post by sgerenser »

bayindirh wrote: post #4
aplummer wrote: post #3

Earlier quoted context omitted.

Have you filed a feedback? Seems like the right next step.

The post opens with the following TL;DR:, snipped for brevity: > It would be great if someone can connect me with the right person inside Apple, or direct them to my feedback request FB17475838 as well as this devlog entry.

Feedbacks often go into a black hole unless either: 1. A bunch of people file effectively the same bug report (unlikely here) 2. An individual Apple employee champions the issue internally 3. Someone makes a fuss on Twitter/X and it starts to go viral

Sounds like the OP is trying to get #2 to happen, which is probably his best bet.

Re: An appeal to Apple from Anukari

#24

Post by viraptor »

aplummer wrote: post #3
humbledrone wrote: post #2

Some folks may have seen my Show HN post for Anukari here: https://news.ycombinator.com/item?id=43873074 In that thread, the topic of macOS performance came up there. Basically Anukari works great for most people on Apple silicon, including base-model M1 hardware. I've done all my testing on a base M1 and it works wonderfully. The hardware is incredible. But to make it work, I had to implement an unholy abomination o…

Have you filed a feedback? Seems like the right next step.

Feedback is as effective as creating a change.org petition to some politician to stop doing crimes please. You'll be lucky to get an acknowledgement that something's a real issue after months.

Re: An appeal to Apple from Anukari

#25

Post by tonyarkles »

madeofpalk wrote: post #15
grishka wrote: post #10

Earlier quoted context omitted.

There already is an unending number of ways for just one app to waste charge on battery-powered devices. It all already relies on developers not unnecessarily running energy-intensive tasks, either intentionally or accidentally. Adding one more API that has the potential to waste energy if not used appropriately will not change that.

macOS also has a bunch of mechanisms to inform the user about this! IIRC the battery menu has entries for apps draining a lot of power (iterm always shows up there for me!)

My potentially incorrect understanding is that iTerm generally only shows up when the processes you run inside it are consuming a bunch of energy. It only shows up in the battery menu for me when I’m running simulations or other big CPU intensive stuff on the command line.

Re: An appeal to Apple from Anukari

#26

Post by grandinj »

Someone wrote: post #12

One thing I don’t understand: if latency is important for this use case, why isn’t the CPU busy preparing the next GPU ‘job’ while a GPU ‘job’ is running? Is that a limitation of the audio plug-in APIs?

this might trick the heuristics in the right direction ie. feed the GPU a bunch of small tasks (i.e. with a small number of samples) instead of big tasks.

Re: An appeal to Apple from Anukari

#27

Post by zamadatix »

LiamPowell wrote: post #7

The problem with exposing an API for this is that far too many developers will force the highest performance state all the time. I don't know if there's really a good way to stop that and have the API at the same time.

Abusing the API would still be more efficient than running fake busy workloads to do the same, which apps can already fo without the API (or permissions the API could require).

Re: An appeal to Apple from Anukari

#28

Post by kllrnohj »

Someone wrote: post #12

One thing I don’t understand: if latency is important for this use case, why isn’t the CPU busy preparing the next GPU ‘job’ while a GPU ‘job’ is running? Is that a limitation of the audio plug-in APIs?

That's pipelining and it's good for throughput but it sacrifices latency. Audio is not a continuous bit stream but a series of small packets. To begin working on the next one on the CPU while the previous one is on the GPU requires 2 samples in flight which necessarily means higher latency

Re: An appeal to Apple from Anukari

#29

Post by my123 »

humbledrone wrote: post #2

Some folks may have seen my Show HN post for Anukari here: https://news.ycombinator.com/item?id=43873074 In that thread, the topic of macOS performance came up there. Basically Anukari works great for most people on Apple silicon, including base-model M1 hardware. I've done all my testing on a base M1 and it works wonderfully. The hardware is incredible. But to make it work, I had to implement an unholy abomination o…

Did you try this entitlement? https://developer.apple.com/documentation/bundleresources/en...

wonder if com.apple.developer.sustained-execution also goes the other way around...

Re: An appeal to Apple from Anukari

#30

Post by thraway3837 »

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is.

Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but still never allowing the basics that every other developer platform has made possible on day 1.

A broken UI system that is confusing and quickly becomes undebuggable once you do anything complex. Replaces Autolayout but over a decade of apps have to transition over. Combine framework? Is it dead? Is it alive? Networking APIs that require the use of a 3rd party library because the native APIs don’t even handle the basics easily. Core data a complete mess of a local storage system, still not thread safe. Xcode. The only IDE forced on you by Apple while possibly being the worst rated app on the store. Every update is a nearly 1 hour process of unxipping (yes, .xip) that needs verification and if you skip it, you could potentially have bad actors code inject into your application from within a bad copy of Xcode unbeknownst to you. And it crashes all the time. Swift? Ha. Unused everywhere else but Apple platforms. Swift on server is dead. IBM pulled out over 5 years ago and no one wants to use Swift anywhere but Apple because it’s required.

The list goes on. Yet, Apple developers love to be abused by corporate. Ever talk to DTS or their 1-1 WWDC sessions? It’s some of the most condescending, out of touch experience. “You have to use our API this way, and there’s this trick of setting it to this but then change to that and it’ll work. Undocumented but now you know!”

Just leave the platform and make it work cross platform. That’s the only way Apple will ever learn that people don’t want to put up with their nonsense.

Post reply on HN