2 ms·

It's weird how on one hand, Apple is pushing the envelope with graphics rendering, but they have been funneling absolutely everyone into Swift for years. They r

It's weird how on one hand, Apple is pushing the envelope with graphics rendering, but they have been funneling absolutely everyone into Swift for years. They recently released metal-cpp to help developers that have existing C++ codebases bring them to apple by dropping in header files that bridge to Objective-C, it's hacky and unwieldly but kind of works I guess. It's especially weird to me considering how nice Metal is to work with, but neither swift not some hacky ObjC/C++ approach seem suited to the task of pushing the envelope of graphics rendering to take full advantage of this hardware. Am I off base here? Honestly, I hope this takes off is really successful, and kicks off enough investment in competitors so that I can hack on cool stuff in another software ecosystem.

drawkbox 3y ago
Apple merely added these libraries to an already existing system to better link Swift to C++/Objective-C++. Objective-C/C++ and C/C++ work well together and always have, it is pretty much required as nearly all game engines (even Unity/Unreal) are C++ underneath just like all apps. Apple did recently add better support for mixing Objective-C++/C++ to Swift which was more difficult before. [1][2][3] Swift to C++ had more leaps prior to recent updates though it was still possible. Really it just handles the Swift to Objective-C++ to C++ link better. Objective-C++ has been used since iOS inception to link C++ game engines to Objective-C. All you have to do is compile with g++ or other and typically files with .m are Objective-C only and files with .mm are Objective-C++. Objective-C/C++ and interop with C/C++ actually works really well and every single game engine on the store (pretty much ever game) uses Objective-C++ to link them at a minimum. We used lots of C++, Objective-C and even Objective C++ (g++ mixing Objective-C + C++, connecting to C++ engine) in a custom game engine that worked on mobile for lots of shipped titles. It is powerful and fun. People have been mixing assembly, C/C++, Objective-C/C++ since the 80s. These technologies so close to the metal and machine code actually work better together than most "modern" frameworks/systems. A sample of early game engines using this link is Oolong from 2008ish, that was used on an early Quake port and many game studios had something like this for custom engines to get them to the iPhone/iPad/etc. [4] Fun fact: Objective-C was created before C++. Objective-C all they way back to 1981 but officially 1984. [5] C++ all the way back to 1982 but officially 1985. [6] [1] https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/ [2] https://developer.apple.com/documentation/Swift/UsingC++APIsInSwiftAndSwiftAPIsInC++ https://developer.apple.com/documentation/Swift/UsingC++APIs... [3] https://developer.apple.com/videos/play/wwdc2023/10172/ https://developer.apple.com/videos/play/wwdc2023/10172/ [4] https://code.google.com/archive/p/oolongengine/ https://code.google.com/archive/p/oolongengine/ [5] https://en.wikipedia.org/wiki/Objective-C#History https://en.wikipedia.org/wiki/Objective-C#History [6] https://en.wikipedia.org/wiki/C++#History https://en.wikipedia.org/wiki/C++#History
winterismute 3y ago
Metal is a modern - and under many points of view, pretty good - rendering API that allows you, for example, to declare the rendering pipelines/dispatches fully without you having to call multiple "change_state" in your CPU code (similar to DX12, Vulkan etc). This means the GPU can run "flat out" and that a driver can be pretty lean and introduce little overhead (if done well enough). In more advanced cases when many API commands need to be encoded depending on users' input, and if batching is not enough, you can use things like "MTLParallelRenderCommandEncoder" and multiple queues to take adavantage of multiple threads submitting such commands. This all means that "pushing the envelope" in terms of rendering is absolutely possible despite the possibly small overhead added by Obj-C - which however also brings some advantages as it often avoids having to call "free" on GPU memory since the MTLBuffers are reference-counted.
pzo 3y ago
I think apple forcing using metal is a mistake. They don't have moat here - nvidia has with CUDA. All those CV researchers using mostly CUDA or OpenCL and they are not gonna learn metal because they probably not in even Apple ecosystem. Apple dropped ball on OpenCL. Plenty of useful algorithms and GPU computing frameworks but barely anything available with metal backend. Libraries like OpenSYCL, OpenCV, Open3d, PCL don't have any Apple GPU backend.

drawkbox 3y ago

Apple merely added these libraries to an already existing system to better link Swift to C++/Objective-C++. Objective-C/C++ and C/C++ work well together and always have, it is pretty much required as nearly all game engines (even Unity/Unreal) are C++ underneath just like all apps. Apple did recently add better support for mixing Objective-C++/C++ to Swift which was more difficult before. [1][2][3] Swift to C++ had more leaps prior to recent updates though it was still possible. Really it just handles the Swift to Objective-C++ to C++ link better. Objective-C++ has been used since iOS inception to link C++ game engines to Objective-C. All you have to do is compile with g++ or other and typically files with .m are Objective-C only and files with .mm are Objective-C++. Objective-C/C++ and interop with C/C++ actually works really well and every single game engine on the store (pretty much ever game) uses Objective-C++ to link them at a minimum. We used lots of C++, Objective-C and even Objective C++ (g++ mixing Objective-C + C++, connecting to C++ engine) in a custom game engine that worked on mobile for lots of shipped titles. It is powerful and fun. People have been mixing assembly, C/C++, Objective-C/C++ since the 80s. These technologies so close to the metal and machine code actually work better together than most "modern" frameworks/systems. A sample of early game engines using this link is Oolong from 2008ish, that was used on an early Quake port and many game studios had something like this for custom engines to get them to the iPhone/iPad/etc. [4] Fun fact: Objective-C was created before C++. Objective-C all they way back to 1981 but officially 1984. [5] C++ all the way back to 1982 but officially 1985. [6] [1] https://www.swift.org/documentation/cxx-interop/ https://www.swift.org/documentation/cxx-interop/ [2] https://developer.apple.com/documentation/Swift/UsingC++APIsInSwiftAndSwiftAPIsInC++ https://developer.apple.com/documentation/Swift/UsingC++APIs... [3] https://developer.apple.com/videos/play/wwdc2023/10172/ https://developer.apple.com/videos/play/wwdc2023/10172/ [4] https://code.google.com/archive/p/oolongengine/ https://code.google.com/archive/p/oolongengine/ [5] https://en.wikipedia.org/wiki/Objective-C#History https://en.wikipedia.org/wiki/Objective-C#History [6] https://en.wikipedia.org/wiki/C++#History https://en.wikipedia.org/wiki/C++#History

winterismute 3y ago

Metal is a modern - and under many points of view, pretty good - rendering API that allows you, for example, to declare the rendering pipelines/dispatches fully without you having to call multiple "change_state" in your CPU code (similar to DX12, Vulkan etc). This means the GPU can run "flat out" and that a driver can be pretty lean and introduce little overhead (if done well enough). In more advanced cases when many API commands need to be encoded depending on users' input, and if batching is not enough, you can use things like "MTLParallelRenderCommandEncoder" and multiple queues to take adavantage of multiple threads submitting such commands. This all means that "pushing the envelope" in terms of rendering is absolutely possible despite the possibly small overhead added by Obj-C - which however also brings some advantages as it often avoids having to call "free" on GPU memory since the MTLBuffers are reference-counted.

pzo 3y ago

I think apple forcing using metal is a mistake. They don't have moat here - nvidia has with CUDA. All those CV researchers using mostly CUDA or OpenCL and they are not gonna learn metal because they probably not in even Apple ecosystem. Apple dropped ball on OpenCL. Plenty of useful algorithms and GPU computing frameworks but barely anything available with metal backend. Libraries like OpenSYCL, OpenCV, Open3d, PCL don't have any Apple GPU backend.