5 ms·
Maybe it's just me but when a write-up about a porting process keeps repeating "it was a breeze", "the results are great", and maintenance is "effortless" and n
by TonyTrapp 6y ago
Maybe it's just me but when a write-up about a porting process keeps repeating "it was a breeze", "the results are great", and maintenance is "effortless" and not a single negative point or writing about something going wrong - it feels fishy to me. Maybe their API abstraction is really good, which could explain it - but there's hardly any words spent on that (and if that's the case, THAT would be absolutely worth writing about, and not a specific API itself).
- gigatexal 6y agoYeah. Stay in this industry long enough and you’ll realize that there’s no silver bullet API that is just magic and perfect. It’s good to be suspicious.
- WrtCdEvrydy 6y ago$10 says this guy got told by the developers it was a breeze so he'd leave them alone.
- simonh 6y agoForm the article: >I got the port that rendered most things in a suboptimal fashion running in about 10 hours in a single day, and spent two more weeks cleaning up the code... So the author is a developer. How do you want to transfer me the $10?
- WrtCdEvrydy 6y agoDamn, cashapp or paypal.
- simonh 6y agoIt's all good ;)
- auggierose 6y agoUsing Metal IS a breeze. Three years ago I had no experience whatsoever with GPU computing. I learnt it through Metal, and it was a great experience with very few hiccups.
- flohofwoe 6y agoYou'll have to use Metal to understand why it is praised so much (by those who actually used it at least). It really is a joy to use, at least compared to Vulkan or OpenGL. It feels a lot like D3D11, which is also (mostly) a very well-designed 3D API, and Metal fixed the few warts of D3D11 and modernized its concepts (like adding render passes, pipeline state objects and command buffers). And D3D11 backend code is very easy to "port" to Metal, so a new Metal backend fits well under existing wrapper APIs which already had to deal with D3D11 anyway.
- Jasper_ 6y agoI will say MSL and associated tooling is horrendous. I like MSL as a language but it pays a heavy price for "being different", it's woefully underspec'd, even compared to HLSL, and the tooling is pretty miserable. You couldn't even run the Metal compiler on Windows until very recently. But I love a lot of the actual Metal APIs.
- flohofwoe 6y agoAgreed, C++ for the shading language was a very strange choice, I'd have preferred regular C with language extensions (I guess we're lucky it's not Objective-C or Swift, really dodged a bullet there). I don't write Metal shader code though, instead I write GLSL and cross-compile to MSL via SPIRVTool + SPIRVCross (HLSL to MSL would work too, but I don't know if that's as well supported as GLSL to MSL). Ideally I'd want to see shader compilers merged into regular compilers, so that "CPU code" and "GPU code" can be mixed in the same source file and share the same data structures (at least their declarations). Actually, the latter (sharing struct declarations via shared headers) works in Metal + MSL though.
- pjmlp 6y agoOptix 7 is based on CUDA (with its C++17 support). What you are looking for is basically CUDA's model, and what Khronos is trying to catch up with SYSCL.
- monocasa 6y agoThey already had backends for desktop, mobile, and console APIs. I imagine them not having to do anything major to support the new API in their engine helped. That being said, Metal is nice to use form a tooling perspective too.