15 ms·
I wonder if support for OpenGL, Vulkan, etc will improve now that Apple is partnering with nVidia, Adobe, Autodesk, Microsoft, etc around the OpenUSD rendering/
by softfalcon 3y ago
I wonder if support for OpenGL, Vulkan, etc will improve now that Apple is partnering with nVidia, Adobe, Autodesk, Microsoft, etc around the OpenUSD rendering/animation/CAD/3D-scene format?
Considering the whole schtick of OpenUSD is "one file format that renders consistently everywhere" (paraphrasing), I would be surprised if Apple doesn't use it as a means to cement more 3D software vendors into macOS land. It's really hard to render consistently if the underlying drivers are all wonk and proprietary.
I am curious to see how this plays out. In my mind, there are two options:
1. Apple conforms to the existing standards of OpenGL and Vulkan we see gaining steam for many film and game production pipelines.
2. Apple tries to throw its weight around and force devs to support their Metal standards even more, ultimately hoping to force the world onto Metal + macOS.
My heart hopes for option 1, but my gut tells me Apple is going to push for option 2 with all the might it can muster. In my experience, Apple doesn't like any standards it doesn't control with an iron fist (not really saying much about Apple here though... nVidia, Autodesk, Adobe, and Microsoft are all the same).
The next couple of years are going to be interesting for sure!
- gumby 3y ago> In my experience, Apple doesn't like any standards it doesn't control with an iron fist I would add some nuance to this statement: "Apple likes open standards when it is weak." The iMac and early OS X went big on open standards, and Jobs made a point of pointing this out: USB for the iMac, JPEG, MPG, mp3, Postscript etc for OSX. IP/TCP built in. They even paid the danegeld for .rtf. Then as they clawed their way back from the precipice, they started "adding value" again. The iphone was an HTML device, loudly repudiating the proprietary (and terrible) Flash much less the crappy, mostly stillborn "mobile HTML" attempts. You still get H.264, matter/threads, and other standards they don't control, where they don't have market power.
- colechristensen 3y ago> "Apple likes open standards when it is weak." Everyone does. AMD is the same. The market leader focuses on features, the runners up try to take them down with openness. The competition is good for consumers, but the motivation is one of self-interest, not the common good.
- i_am_jl 3y ago>The iphone was an HTML device, loudly repudiating the proprietary (and terrible) Flash much less the crappy, mostly stillborn "mobile HTML" attempts. Skipping Flash wasn't so much an ideological decision as a practical one. At the time Steve Jobs listed a ton of reasons that they didn't implement Flash. Listed among them were concerns about it not being an open standard, inferiority to H.264, security and performance issues, etc. However, all of these things could've been ignored or overcome. The principal problem was that a huge proportion of Flash applications, games, and websites used mouseovers as crucial methods of interactions, and Apple simply had no way to allow users to mouseover an element on a touchscreen.
- tomjakubowski 3y agoApple did find a solution in mobile Safari for touchscreen hover states on the Web. However the Web platform generally offers more affordances for accessibility than Flash ever did, which I'm sure helps.
- i_am_jl 3y agoIf I'm not mistaken the solution was to make touching an element trigger the :hover state and the click action unless the :hover state changed the visibility of another element. If the :hover state changed the visibility of another element, then the click action was not triggered until a user tapped again. This is possible in HTML because it's trivial to determine whether or not a :hover changes display or visibility properties of other elements. As you've supposed, Flash did not afford browsers with that sort of ability.
- gumby 3y ago> more affordances for accessibility than Flash ever did TBF one thing Flash did manage to achieve was the proliferation of web sites and apps that were as hard to use for people without protected disabilities as for people who did have them. Whether this increased empathy for people with disabilities is an open question
- jjoonathan 3y agoThat could have been overcome. The general crustiness of flash could not have been (from Apple's POV). Apple used to ship a dev app called "Spin Control" that would log stack traces whenever an app failed to drain its event queue in a timely manner (i.e. beachball). One time I accidentally left this open for an entire week, went about a bunch of assorted business, and when I came back every single stack trace had to do with flash, and there were many. Either flash in a browser or flash in a browser embedded in something else (ads embedded in 404 pages for broken help pages that were never even displayed, lol). At first I thought it had to be a mistake, a filter I had forgotten about or something, so I triggered a spin in Mail.app by asking it to reindex and sure enough that showed up as the first non-Flash entry in Spin Control. As hard as it was to believe: Flash had been responsible for every single beachball that week. Yikes.
- foobiekr 3y agoYou might actually expand "Apple likes open standards when it is weak" to "companies likes open standards when they are weak." Generally speaking you get standards consortiums when there is a clear winner that is mopping up the space. Here's an example that's happening right now: Nvidia-NvLink-Infiniband. Nvidia owns the highspeed interconnect inside the chassis (HGX), the NICs (Mellanox), the inter-host interconnect (Infiniband), the high performance inter-host interconnect (switched NvLink), the and the ethernet network (Mellanox has the same 52.1Tbps switch performance that everyone else has now). GPU training is RDMA heavy and this is a place where both NvLink and Infiniband shine, ethernet much less so. Retransmissions are very bad, in global-performance-terms, for ROCEv2 transfers. Right now Nvidia is just crushing it and there's zero chance anyone is going to catch up by introducing new Infiniband ASICs. So what happens? You have a consortium spun up by all of the companies in the Ethernet space - Ultra Ethernet Consortium - to try and use "standards" to push back on customers who don't want to make big investments in "non-standard." UEC is pretty vague but seems to be promising Broadcom-style cellized fabrics, the whole point of which is to have an ethernet-like standard that avoids ECMP-induced flow collisions and retransmissions - that is, get Ethernet into the same territory as Infiniband. If you look back in time in the tech industry, you see this over and over and over and over. Standards are great, they make certain kinds of multi-sided markets and markets that need broad participation to be viable possible - but they are also routinely about the losers joining together to compete.
- paulmd 3y agoSame for adaptive sync. Gsync was first to market by a country mile, the adaptive sync standard wasn’t even approved until like 6 months after the first gsync stuff showed up and if nvidia hadn’t gone first it would have taken much longer if it happened at all. Freesync wasn’t really market-ready until at least 2015 and the early products were mostly junk, it’s not until the gsync compatible program that any vendors really cared about LFC or flickering issues.
- SergeAx 3y ago> losers joining together to compete You are saying it like it is something bad. Competition is good for consumers, and I cheer any means to spin up, sustain and heat competition.
- JohnBooty 3y agoThen as they clawed their way back from the precipice, they started "adding value" again. I don't know if I can agree. On the software side, MacOS supports all those things. On the hardware side, it's still (edit: almost) nothing but industry-standard ports.
- gumby 3y agoI didn't say they necessarily denigrated the open formats but added and preferred their own proprietary image, audio etc formats as they gained market strength. On the hardware side I'm delighted by Apple's USB C/TB push (and Apple contributed a lot to those standards, esp based on what they had learned with Lightning) but note they revived the proprietary "magsafe" connecter on recent laptops (though you can still use USB C PD). Apparently enough customers wanted it. And as others have pointed out, Apple is hardly alone in this
- als0 3y ago> Apparently enough customers wanted it. Magsafe is genuinely a nice innovation that users missed. It solves the cord yank problem. But I do like having the option to use USB-C if I don't have the MagSafe cable.
- memefrog 3y agoAlso USB-C absolutely sucks. The socket seems to attract dirt and dust in a way that prevents its proper working like no other.
- brokenmachine 3y agoI have lots of USB-C devices and never had that problem. I'm careful with my stuff though.
- Unfrozen0688 3y agoPhones are very sensitive to it as they are in a pocket. Pocket lint -> pushed in USB cable -> after some years the connector wont connect anymore
- mattl 3y agoNeXT had RTF support. It was used everywhere including NeXTmail
- simonh 3y agoOr even “Apple doesn’t like open standards that are weak”. OpenGL was just no longer fit for purpose. They were competing against DirectX, needed to do ML acceleration, and at the time Vulcan didn’t exist. They had to do something, and especially given their chip strategy that must have been in full swing at the same time, Metal must have been a no brainier.
- nixpulvis 3y agoBig tangent, but can someone tell me why matter/threads doesn’t suck ass? I have one of these devices and frankly I have no idea what I expect it to be doing.
- aleph_minus_one 3y ago> I would add some nuance to this statement: "Apple likes open standards when it is weak." > [...] > Then as they clawed their way back from the precipice, they started "adding value" again. Just four words: embrace, extend, and extinguish > https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
- zamadatix 3y agoOpenUSD is a way of bundling and specifying the data to be rendered. It doesn't relate to which API the app uses to accelerate rendering. Adobe, Autodesk, Blender, and most others support different backends per operating system including Metal on macOS already.
- softfalcon 3y agoYeah, I know it's just a file format for scene description. I still believe rendering would work better for the industry as a whole if they could agree to all support, say, Vulkan. I doubt it'll ever happen, but a consistent graphics driver/API standard across operating systems would be pretty rad.
- zamadatix 3y agoWhile not at the kernel level I think WebGPU is probably better than something like Vulkan for that "I can target this low level access to the GPU resources but expect it to work everywhere" use case. Ignoring the name hint that it was designed for the web (it works fine outside the browser), it's a lot more portable than Vulkan across its various implementations precisely because it needed to work on various devices that could browse the web. It's also already backed and supported by all the big players, including Apple.
- softfalcon 3y agoI'm a big fan of webGPU. I use it within my Three.js projects. Really happy to see it gaining support worldwide. I hope either it or similar projects continue to gain traction!
- geokon 3y agoOut of idle curiosity I thought I'd give it a try. Maybe run a demo on the REPL in Clojure. I try to Google "Java WebGPU" and I get no real results I could be wrong but It seems it's technically possible to use it outside the web, but the ecosystem looks halfbaked
- dicriseg 3y ago> In my experience, Apple doesn't like any standards it doesn't control with an iron fist Apple supports a number of open standards. I think I’d modify your statement to say Apple doesn’t want to depend on any standards it doesn’t control. And while that may appear nefarious, I get Apple’s implied position there. They have really tight coupling between hardware and software in order to deliver on the UX that they intend (whether or not you like all or some of it). If they’re designing their own software and hardware, I can see why they’d also want to implement standards that they can control to some degree - otherwise their UX is dependent on others. This is also why I think Apple sometimes implements new industry standards, USB-C being one example - if no one else has made an effort yet, they can influence the direction by being first movers.
- JohnBooty 3y agoIn my experience, Apple doesn't like any standards it doesn't control with an iron fist I mean, on one hand, the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. On the other hand I'm sitting here typing on a Mac with nothing but USB-C ports that is connected to half a dozen peripherals and a big ol' monitor over those standard ports using standard protocols. In general I feel that Apple prefers open standards when they actually suffice. USB2 couldn't do a lot of the things that Lightning did, so they invented that. Now that USB-C exists, they embraced it immediately on the Mac and iPad but are unfortunately dragging their feet w.r.t. the iPhone.
- ribit 3y ago> the Metal/Vulkan/OpenGL situation is unfortunate and I don't understand Apple's motivation there. I don't think it's hard to understand. Apple wanted an easy to use API that could be extended and updated easily. Vulkan is an extremely complex API that foregoes all and any developer ergonomy to facilitate quick driver development on as many hardware targets as possible. Consequently, Vulkan's design choices are driven by the least common denominator. The goals are just too different. There is at least some evidence that Apple was interested in supporting and shaping Vulkan (they were member of the initial working group), but I suspect that it very quickly became clear that the committee is going into a direction they were not interested in, so they noted out. Still, I don't think it's correct that Apple is opposing any kind of standardisation in this domain, they just want something more aligned with their vision. They have been very active with WebGPU, which is shaping up to be a very nice API, and it has inherited a lot of good design decisions from Metal.
- fayalalebrun 3y agoIndeed Apple has been very active in shaping WebGPU, and that is why we can't use a bytecode representation for shaders. Instead, we have to repeat OpenGL's mistakes and store shaders as strings. WebGPU specifically has to be the lowest common denominator among the APIs it supports. And there are several features very useful in GPGPU's which are supported in Vulkan and CUDA, but cannot be included in WebGPU due to the lack of Metal support. One such example is floating point atomics.
- bookmark1231 3y agoI don’t think that’s the shtick behind OpenUSD. It’s not a transmission format like glTF, so the intent is not to get consistent rendering but rather to standardize intermediate graphics representations so that software that works on 3D scenes (unreal, Maya etc) can represent all of their workflow in USD and get consistent interop.
- softfalcon 3y agoSomeone should tell Jensen Huang then. That's the message he pushed heavily at Siggraph 2023 over and over and over again. Source: https://www.youtube.com/watch?v=Z2VBKerS63A https://www.youtube.com/watch?v=Z2VBKerS63A They even did a big demo shot showing the same frame being rendered in multiple different editors all creating the same consistent result and matching. All of it was said to be due to OpenUSD standardizing how a scene is defined, animated, and rendered. Probably just a bunch of marketing buzz though.
- WhereIsTheTruth 3y ago> 1. Apple conforms to the existing standards of OpenGL and Vulkan we see gaining steam for many film and game production pipelines. Read what gamedevs have to say about this, Metal is more appreciated than Vulkan > 2. Apple tries to throw its weight around and force devs to support their Metal standards even more, ultimately hoping to force the world onto Metal + macOS. Apple was part of the Vulkan working group, knowing what gamedevs prefer, it now make sense why they parted away and created Metal instead In retrospect I can only show compassion to Apple, they made the right choice
- deleted 3y ago[deleted]
- memefrog 3y agoVulkan is way better than Metal. Metal is simpler to learn. That is about it.
- ribit 3y agoNonsense. Feature-wise, they are mostly equivalent (Metal has better support for GPU driven pipelines and shader authoring). Metal is much simpler and more flexible. The only way Vulkan is "better" if you measure lines of codes.
- anaki 3y agoVulkan is surely more flexible. One example off the top of my head is mailbox presentation mode in Vulkan for minimal input delay without tearing.
- ribit 3y agoMetal allows you to present surfaces at exact times. You have access to the display refresh timing information and it's your job to synchronise your drawing rate to (potentially variable) display presentation interval. Vulkan presentation modes are workarounds over the fact that Vulkan provides no fine-grained control over presentation intervals. There is the VK_GOOGLE_display_timing extension that provides functionality similar to Metal, but it doesn't seem like it's well supported on desktop. The equivalent official extension seems to be stuck in limbo somewhere.
- scarface_74 3y ago> Apple doesn't like any standards it doesn't control with an iron fist You mean like SCSI, FireWire, USB-A, USB-C, USB 3.x, Bluetooth, Qi charging, H264, AAC?
- dgellow 3y agoStill no iPhone with USB-C :(
- scarface_74 3y agoThis year definitely because of the EU mandate. It will probably still be nerfed like the low end iPad that has USB C. But still transfers at USB 2 speeds
- dgellow 3y agoFine for me, I never transferred anything over a wire between my phone and another device. It’s way more annoying to have to deal with a different charger.
- jorvi 3y agoI honestly don’t get why people are so furious about this. I asked my two siblings, two friends from my uni days and two friends from work and none of them have used the Lightning (soon to be USB-C) port for anything but charging and music. None of them even remember connecting it to a computer past the iPhone 5S.
- overgard 3y agoApple is definitely not going back to OpenGL. I can't say I'm particularly sad, OpenGL is very long in the tooth and writing a good driver for it seems like a nightmare, considering how hard it is to even write good performant application OpenGL code. I wish they had thrown in behind Vulkan instead of creating Metal, but it seems like outside of linux vulkan is a second class citizen everywhere (although it's a pretty good second class citizen to target). In terms of supporting games or steam and such, I think the reality is that a large segment of games now use engines that handle the API stuff for you, and if you do have the resources/time/inclination to write directly to the API, you're probably ok with MoltenVK as long as you're not doing anything too cutting edge. Seriously though, while I've written OpenGL most of my life to be cross platform and support the most I can, it's an absolutely TERRIBLE api. Global state everywhere, tons of functions you can-but-shouldn't-use, all sorts of traps everywhere, monsterous header files for extensions, incredibly hard to debug. Vulkan is verbose but in a lot of ways it's actually easier, even if it's advertised as being the more hardcore way to do things.
- coldtea 3y ago>I wonder if support for OpenGL, Vulkan, etc will improve now that Apple is partnering with nVidia, Adobe, Autodesk, Microsoft, etc around the OpenUSD rendering/animation/CAD/3D-scene format? I'd say it's totally orthogonal matter (having a standard 3D scene format, and what graphics api will render it), and Apple's participation on that will be minimal anyway. >I would be surprised if Apple doesn't use it as a means to cement more 3D software vendors into macOS land. It's really hard to render consistently if the underlying drivers are all wonk and proprietary. There's an easy fix though Apple can suggest: just use the official macOS engine. Why would the even opt for (1)? To burden themselves with supporting different 3D engines? They already support and maintain their own.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- jjtheblunt 3y ago> In my experience, Apple doesn't like any standards it doesn't control with an iron fist what about MacOS being a Unix? I'd suggest a deeper diagnosis is that Apple doesn't like standards incapable of showing off or leveraging custom hardware prowess, which is a key competitive advantage.
- meindnoch 3y agoUSD is a file format. It doesn't have anything to do with the underlying graphics APIs. In fact, tailoring your file format to the underlying graphics APIs is pretty dumb. (like glTF specifying OpenGL constants like 9729, 9987, etc.)
- softfalcon 3y agoI didn't mean to say they should tailor the file format to the graphics API. I more meant, when a scene format becomes popular, usually you see multiple engines/pipelines/libraries support the underlying scene descriptors like material files, physically based rendering profiles, animation keying, etc. I wouldn't want the file format dictated by the graphics API, but I would like consistent rendering output in multiple places for the same file. That'd be cool. In case you're wondering where this "conformance" idea came from, check nVidia's 2023 Siggraph talk. Jensen will buzz word OpenUSD and conformity across products until your ears bleed. Siggraph 2023 nVidia: https://www.youtube.com/watch?v=Z2VBKerS63A https://www.youtube.com/watch?v=Z2VBKerS63A (in case it wasn't obvious, I am skeptical this will ever really happen, I imagine this is all marketing speak)
- meindnoch 3y agoConsistent rendering is only possible when the material models used by the various engines are similar enough. Physically-based renderers produce pretty similar results for basic diffuse-metallic-clearcoat, etc. materials. Where things become hairy are more advanced effects like refraction, subsurface scattering, ambient occlusion etc., where different engines use different techniques with different tradeoffs, because there's no easy one-size-fits-all implementation. The UsdPreviewSurface part of the USD spec doesn't even support many of these advanced effects. If your scene uses these effects a lot, then consistent rendering is less likely.
- ribit 3y agoApple's strategy for cross-platform GPU is WebGPU, which they are actively involved in. OpenGL has been obsolete for a while and Apple has no interest in supporting Vulkan (for multiple reasons). The core philosophy of Vulkan — which is designed as a least common denominator abstraction to facilitate fast driver development, with no regards to end developer convenience — is at odds with what Apple wanted (a compact, easy to use API with progressive manual control knobs). Current Metal is essentially a more streamlined and user-friendly DX12 Ultimate, plus a mix of some console-like functionality and Apple-specific features, plus Nvidia Optix, plus a subset of CUDA features (such as cooperative matrix multiplication). Plus they have a very nice shading language and some neat tools to generate and specialise shaders. I expect them to continue gaining feature parity with CUDA going forward (things like shared virtual memory might need new hardware). They simply can't offer such comprehensive feature set in a reasonable fashion if they went with Vulkan, even if we let the issue of usability aside for a moment (and we really shouldn't, as Vulkan is horrible to use).
- softfalcon 3y agoI was unaware that Apple was helping implement WebGPU! I actually love WebGPU, it looks great and pairs very nicely with three.js which is a favourite hobby tool of mine to use on pet projects. I can tell you have strong opinions on Vulkan. I don't disagree with your general view that it's hard to work with development wise as it's very tied down to driver and hardware implementation specifics. What I can say though, is that I've met several pipeline rendering engineers (think folks who invent render engines for film and write low level game engine code) who seem to love Vulkan. They appreciate being able to really get down to the bare metal of the drivers and eek out the performance and conformity they need for the rest of the game or render engine. A lot of the frustration with OpenGL/DirectX from these specialists was their inability to "get in there" and force the GPU to do what they really wanted. Vulkan apparently gives them a lot more control. As a result, they are able to accomplish things that were previously impossible. All that being said, I think WebGPU will be far more popular for 99% of developers. Only a very few folks like getting down into the nitty-gritty of libraries like Vulkan. At the same time, there is huge money to be made knowing how to make a game eek out another 10 FPS or properly render a complex scene for a film group like Pixar who wants to save days on a scene render.