61–70 of 131 posts
From the article, it would seem that compensating via software was fine (performance wise). Apple’s approach seems to be seems to break the norm in fields where the norm has proven to be unnecessary complexity. Which open tip room for just more raw performance.
Well written. Well done.
Earlier quoted context omitted.
This is the advantage of building your hardware and your software under the same roof. You can make optimizations (such as not including hardware that makes OpenGL faster, but doesn't impact Metal nearly as much.) The "standard" here is the Metal API, not the GPU hardware.
I don't think it's an advantage to sabotage the adoption of common API like Vulkan. It holds the progress back and I totally blame Apple for pointless NIH and lack of collaboration here. Apple are doing it out of rather sickening lock-in culture in the company and Metal is far from the only example like that.
I don’t disagree, but what else they could possibly do?
Metal shipped in 2014 for iOS, in 2015 for OSX. Vulkan 1.0 was released in 2016.
I don’t think it was reasonable to postpone long overdue next gen GPU API for a few years, waiting for some consortium (outside of their control) to come up with API specs. By the time Vulkan 1.0 has released, people were using Metal for couple years already.
Unrelated - All this work is done by an 18 year old. Absolutely incredible. Some people are simply built differently and admittedly, it makes me jealous.
During my time it meant:
- Knowledge of BASIC (GW, Turbo and Quick), Turbo Pascal, Turbo C, Turbo C++, 80x86 Assembly, dBase III Plus and Clipper
- Databases and their data organization on harddisk
- Digital circuits
- OS design, with experience on MS-DOS/Netware and Xenix
- 3 months trainship at the end of the degree into a local company
- All the remaining stuff on traditional high schol like physics, math, geometry and whatever else.
Now would everyone be as good as she is?
Certainly not, but the tools are there for anyone that wants to have a go at it.
Earlier quoted context omitted.
You're talking about macOS. We're talking about AGX2. If you want to complain about Apple's API support in macOS, a discussion about AGX2 support for Linux is not the right venue. I am, quite honestly, getting very tired of all the off-topic gratuitous Apple bashing in articles about our Linux porting project.
The article points out that their API matches the hardware and it's the only API they care about: > Their only properly supported API is their own Metal, which they may shape to fit the hardware rather than contorting the hardware to match the API. Meaning they don't care to take Vulkan into account when making their GPU. If it would happen to work well - good. If not - tough luck. So it's not just about macOS, it's…
It doesn't make any sense. Of course Apple optimizes Metal for their GPUs and their GPUs for Metal. None of that is hostile towards other APIs. All of this hardware is Turing-complete and by definition can implement any conceivable graphics API. The only question is how well it performs with those APIs, and until we have benchmark numbers, your argument is based on assumptions lacking any evidence.
Earlier quoted context omitted.
I acknowledge that it’s possible to run unsigned code at “ring 0” on M1 MacBooks but the existence of the DRM restrictions leads me to believe that certain DRM-relevant hardware is not accessible unless a signed OS is running. I’m not exactly sure how the attestation works from software to hardware but I have to guess that it exists, otherwise it would be relatively trivial to load a kext that enables 4K DRM with SIP…
The Secure Enclave Processor (SEP) is the part that you cannot run your own code on, and it knows what state the device was booted in. However, it doesn't get in the way of normal OS usage. It also serves as a secure element, e.g. we can use it to store SSH keys and authorize use with Touch ID, or to secure a password store, or as a U2F token, just like macOS does. This is much better than most unlocked Android devic…
> iOS apps should be FairPlay encrypted AIUI, and presumably that goes through the SEP to only authorize decryption when booted in secure mode.
Wow is it really possible that iOS apps are encrypted with a private key that is stored within all SEP devices and it hasn’t been cracked yet? If so that’s incredible and would explain why a workaround for using iOS apps with SIP disabled hasn’t been released. Of course I shouldn’t be that surprised since 4K DRM media content would rely on the same property.
Edit: I looked into this and it turns out that each device has its own public key and the server encrypts the app/content with a key derivable from the device public key on-the-fly at download time. This is a simplified explanation but the essential implication is that there is no global private iOS app package key.
> Besides, I think most of this stuff goes through OS-controlled IOMMUs to access memory anyway, so it can't do much harm to the main OS.
Great point. If these other onboard devices have unfettered access to the memory bus and/or can trigger some sort of NMI then you can never really trust these devices. Though as you point out, most contemporary x86 PCs are no different in that regard.
Earlier quoted context omitted.
I acknowledge that it’s possible to run unsigned code at “ring 0” on M1 MacBooks but the existence of the DRM restrictions leads me to believe that certain DRM-relevant hardware is not accessible unless a signed OS is running. I’m not exactly sure how the attestation works from software to hardware but I have to guess that it exists, otherwise it would be relatively trivial to load a kext that enables 4K DRM with SIP…
The Secure Enclave Processor (SEP) is the part that you cannot run your own code on, and it knows what state the device was booted in. However, it doesn't get in the way of normal OS usage. It also serves as a secure element, e.g. we can use it to store SSH keys and authorize use with Touch ID, or to secure a password store, or as a U2F token, just like macOS does. This is much better than most unlocked Android devic…
Earlier quoted context omitted.
I'll agree with you when they'll support Vulkan properly. Until then I see them as a hostile entity to common GPU APIs adoption.
Why should they support vulkan? what does apple get out of that apart from less well optimised compute and shader code, using more battery and producing more heat for the same output. (the reason it would be less well optimised is Vulkan is an API designed by a group to be the best compromise of many GPU vendors. If apple wanted to support vulkan without it being worse than Metal they would either need to add so many…
A nit:
> For example, I have not encountered hardware for reading vertex attributes or uniform buffer objects. The OpenGL and Vulkan specifications assume dedicated hardware for each, so what’s the catch?
That is not my understanding of those specs (as someone that's written graphics drivers). Uniform Buffer Objects are not a "hardware" thing. They're just a way to communicate uniforms faster than one uniform per API call. What happens on the backend is undefined by those specs and is not remotely tied to some hardware implementation. Vertex Attributes might have been a hardware thing long ago but. I'm pretty sure there are older references but this 9yr old 2012 book already talks about GPUs that don't have hardware based vertex attributes.
https://xeolabs.com/pdfs/OpenGLInsights.pdf chapter 21
Earlier quoted context omitted.
The Secure Enclave Processor (SEP) is the part that you cannot run your own code on, and it knows what state the device was booted in. However, it doesn't get in the way of normal OS usage. It also serves as a secure element, e.g. we can use it to store SSH keys and authorize use with Touch ID, or to secure a password store, or as a U2F token, just like macOS does. This is much better than most unlocked Android devic…
Excellent write up. Thank you > iOS apps should be FairPlay encrypted AIUI, and presumably that goes through the SEP to only authorize decryption when booted in secure mode. Wow is it really possible that iOS apps are encrypted with a private key that is stored within all SEP devices and it hasn’t been cracked yet? If so that’s incredible and would explain why a workaround for using iOS apps with SIP disabled hasn’t…
There are global keys, which are used for system software. iOS used to be encrypted as a whole (not any more though, but the SEP firmware and iBoot still are) and getting those keys is tricky, as they are baked into hardware and different for each generation. You can build hardware so it lets you decrypt content or subkeys with a key, but not access the key material itself; if done properly (it often isn't done properly), that can mean you can only use the devices as an oracle (decrypt anything, but only directly on-device) unless you spend a lot of time and money reverse engineering the baked-in hardware key using a scanning electron microscope.