If I got it right, the statement, where Blender goes was,
we will switch to Vulkan - but don’t expect any acceleration just by this
for now, it is mostly for getting future proof.
I think the same is for metal. In 90% it will not help for speed. But there
is the option to go down more near to “metal” to eliminate some overhead
for very special demanding tasks.
Plus it has a future and will be further supported and developed.
Also I think Metal makes GPU power more accessible to standard developers.
Also astonishing for me in :
There are about 5 times more Mac users than Linux users.
I would have expected the opposite for FOSS Blender.
That looks just like the overall popular usage of specific OSs in general !
(Or I would expect that 80% of FreeCAD users are on Linux.
Maybe also not)
I wrote a Gui client for a text editor (neovim), which originally relied on Vulkan for rendering. About half way through the project, I decided to switch to openGl for a few reasons.
Better compatibility. OpenGL works much better on macOS compared to Vulkan → moltenVK
Better performance, OpenGL for a simple 2d renderer produced better results and sucked less battery compared to the Vulcan backend
MUCH fewer bugs. The Vulkan version was quite glitchy due to things out of my control. Unicode and font support was extremely glitchy, and it almost never worked on HiDpi displays
MoltenVK != metal, and won’t ever be. Its a transition layer, and always will be
Think of it as Wine, its translating windows instructions to macOS, and might have good performance occasionally, but most of the time isn’t worth the hassle. Going pure metal is also an option, but then if you want to target multiple systems (linux, windows, macOS, etc), then It quickly becomes annoying
Cad software on linux generally sucks. For most blender users, they probably have to switch to another cad software from time to time so linux isn’t going to be an option. Programming/dev side of things generally favors linux more
I think theres a bit of confusion. For any 2d rendering, there isn’t much need to switch to Vulkan, metal or anything of the sort. Although it might feel a little snappier, there would be close to no performance difference. The bottleneck in our case is the cpu for viewport rendering, so that isn’t improving for now
If you were to port cycles to Vulcan and run it through MoltenVK, parts of it wouldn’t run. Those are the parts that are going to be required to be ported to metal, since there wouldn’t be another option. The blender developers have stated previously that a proper metal build only for macOS isn’t coming up anytime soon
OpenGL and Metal both have access to the core parts of the graphics card. However, since Metal is a low-level api, you have to write quite a bit more code for it, which may or may not pay off, hence the hesitation most developers face when being asked the question
just to demonstrate the difference, here is an example with a triangle, and the code taken to draw each
CAD :
Proprietary Bricscad runs pretty well on Linux.
For some users.
In fact there is quite a huge gap in reliability of Windows Version
vs Linux and! Mac version. Where Linux feels even a bit better than macOS.
(On the other hand, Modo, basically runs equal on Linux vs Windows or Mac)
But the typical Bricscad User may not be a Blender User.
So yes, and CAD on Linux, unfortunately, is difficult.
I think you may have replied to the wrong person.
I don’t want VulkanVK to be the graphics language for Macs, and not sure why people keep bring up this or mentioning this will be the way, especially after the quote from the head of development for Blender.
I have been talking about Metal and it’s future use inside Blender, not wrappers or other work arounds.
“Basically the current OpenCL kernel implementation is being removed entirely. Performance issues are part of the reason. The way forward will be a Metal backed on macOS. There’s nothing specific we can announce regarding that, but probably it is just a matter of time.” - Brecht
And don’t get me wrong here, Im not in a rush for a full Metal version of Blender (Would Love it but not in a rush).
I pretty much only do character story driven animations in Blender, plus the world building for those scenes, but that’s pretty much it. The new M1s combined with the ARM64 version of Blender have shown to be incredibly powerful in this regards (animation) so I’m more than happy with my current setup with Blender.
Like I’ve stated before, I mostly render on servers because, you know 8000 frame animations.
And for setting up lighting, even in a large dense scenes, the M1 mini has been literally real-time in Eevee and very usable in Cycles.
After BF released the official ARM64 version I’ve been pretty much content, right now, but at no point do I want them to stop advancing the MacOS ARM version of Blender.
In my experience of programming for Apple platforms for 20 years now (gosh, I’m an old man) for functionality this essential, it’s in most better to go native instead of using wrappers to try to make it behave like something it isn’t.
Yeah, although I used the Windows version of MoI 3D inside a WINE wrapper on macOS for a few years, and I had no complaints at all about speed loss. Of course it helped that MoI is coded very efficiently, but I’m glad there’s a native macOS version now.
It should be obvious that MoltenVK is nonsense. Nevertheless, quite experienced people have mentioned the possibility of using it for Blender. This is weird.
I don’t doubt that MoltenVK can be useful in certain cases. CrossOver or Rosetta are also useful.
I’m referring specifically to Blender - it’s absurd to consider using MoltenVK as a target solution.
they need to release a new version of openCL that is crossplatform and has vendor specific drivers / platform specific so blender does not need to worry about this stuff.
Minus Brecht mentioning it in a single post on DevTalk I wasn’t aware of anything more official concerning Metal, until seeing today’s episode of Blender Today. Pablo links to Blender’s official Blog post where it mentions Metal as a future API for Blender.
Nothing definitive… just wanted to share something more official with you guys.
i guess it kind of is half wrong. with a lower level api you need much more boilerplate code but the bigger the application grows beyond drawing a single triangle the less difference in the amount of code there will be.
I did reply to the wrong person, apologies for that. I didn’t notice that blender decided to properly utilize metal instead of molten vk now, thats a very good choice
with a lower level api you need much more boilerplate code but the bigger the application grows beyond drawing a single triangle the less difference in the amount of code there will be.