9 ms·
They aren't "sabotaging" anything, they are making a perfectly normal design trade-off to implement some features in shaders instead of as fixed-function hardwa
by marcan_42 6y ago
They aren't "sabotaging" anything, they are making a perfectly normal design trade-off to implement some features in shaders instead of as fixed-function hardware. By your definition, every modern GPU built in the last decade is "sabotaging" OpenGL 1.x support, because fixed-function vertex and pixel processing hasn't been a thing in that long and it's all done in shaders now, even if you use the legacy APIs.
Alyssa clearly explained how avoiding fixed-function hardware means they can cram more shaders in which means they can increase performance; we have no idea, at this stage, whether this ends up being a net gain or a net loss for, say a Vulkan app. And we probably never will, because we don't have an "AGX-but-it-has-this-stuff-and-fewer-shader-cores-in-the-same-silicon-area" to compare with. And it doesn't matter. In the end OpenGL and Vulkan apps will run fine.
If we ever end up with empirical evidence that these design choices significantly hurt real-world OpenGL and Vulkan workloads in ways which cannot be worked around, you can start complaining about Apple. Until then, there is absolutely no indication that this will be a problem, never mind zero evidence for your conspiracy theory that it was a deliberate attempt by Apple to sabotage other APIs.
- shmerl 6y agoI'll agree with you when they'll support Vulkan properly. Until then I see them as a hostile entity to common GPU APIs adoption.
- marcan_42 6y agoYou'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.
- BolandJ 6y agoShmerl pops up on every thread mentioning Vulkan/Apple spouting conspiracy theory nonsense that every design decision is some kind of evil plan to screw over open standards. Ignore him. Keep up the great work, plenty of people really appreciate it.
- pjmlp 6y agoAnd keeps forgeting no one in the games industry, or console vendors for that matter, cares about his conspiracy theories.
- shmerl 6y agoLock-in proponents bring their kool aid. Not impressed. Gaming industry is pretty messed up when it comes to lock-in. Everyone is paying this tax.
- pjmlp 6y agoI am aware of my limitations as human being in this society, speak from actual work experience, and will use any tooling that I rant about when it is on the best interests of the customers, regardless of my personal agenda. Something to think about, or maybe not.
- glaze 6y agoYup, I doubt he has experience working in the games industry. Many engines support multiple graphics APIs and there's often only 1-2 employees implementing/maintaining them so speaking about vendor lock-in is not a strong argument.
- mlindner 6y agoYes I agree it's tiresome, I wish hacker news had rules against people making bad faith arguments more so than they do now.
- shmerl 6y agoThe 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 about making hardware too. If you don't find it a damaging stance - well, good for you. I find it pretty nasty and I don't see a reason to avoid criticizing Apple. They aren't some neutral party in this especially with their size and impact.
- pertymcpert 6y agoI think you haven't effectively countered their point.
- marcan_42 6y agoYour argument is equivalent to criticizing ARM for putting in instructions to optimize Javascript into their architecture, as if that "sabotages" every other programming language. Or Intel for putting in instructions to optimize AES into their architecture, as if that "sabotages" Salsa20. 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.
- shmerl 6y agoI'm not sure what Turing completeness argument has to do with anything. Turing machine is also Turing complete. You are going to make GPUs like that. We are talking about a simple fact - Apple don't care to collaborate on Vulkan, neither when designing their GPUs nor for their OS. I see no point to further argue about facts. And I see criticism of that as completely valid.
- glaze 6y ago
- hishnash 6y agoWhy 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 apple only extensions that it would be Vulkan in name only or make their GPUs be identical to AMD or Nvidia (unfortunately due to IP patents apple can't just make a copy of AMDs GPUs they need to find another IP partner and that is PowerVR). If PowerVR had 80% of the GPU market (like Nvidia) the would have pushed Vulkan to line up with a TBDR pipeline but they do not so while you can run Vulkan on a TBDR pipeline you end up throwing away lots and lots of optimisations.
- marcan_42 6y agoAGX (and SGX) aren't the only TBDR architecture. ARM Mali GPUs are also TBDR, are in plenty of phones, and run Vulkan just fine.
- thechao 6y agoAnd Larrabee!!! It was the tilyest of them all!
- pjmlp 6y agoAndroid developers wouldn't say phones run Vulkan just fine, unless when talking about Samsung and Google devices. Hence why Google made it a compulsory API on Android 10, to try to tame OEMs in improving their Vulkan story, and yet it is a plain Vulkan 1.1.
- monocasa 6y agoAdding to this, that whole render pass concept in the Vulkan API was the TBDR vendors being very active contributors to the API. More explicitly describing the data flow there allows TBDR arch's to work on multiple parts of modern render graphs simultaneously and keep their tiles filled with work in places where the other synchronization methods wouldn't (or would require the kind of divination on the part of the driver that Vulkan is trying to avoid).