OpenSubdiv has supported using Apple Metal API since version 3.3
@Harleya And how will its rendering be integrated if blender currently doens’t run with metal? Or did I miss something here. Blender on Mac still runs on top of OpenGL if I’m up to date. No?
Hi Phil, I’m running blender on windows, but I’m pretty sure that the workbench, eevee and cycles will run on OpenGL, or OpenCL/Cuda under MacOS at the moment. If you’re talking of Opensubdiv, its gpu accelerated posssibilities aren’t used yet at all in blender, neither under Windows nor MacOS as far as I know. But most parts of blender are “still” running with gpu acceleration under MacOS.
When gpu acceleration for opensubdiv would be implemented I am not sure which path blender will take. The opensubdiv gl backend is just supporting windows and linux and opengl support is about being dropped by apple anyway.
About what will happen in the future with Blender on MacOS I can just guess, I’d say this all takes some time to get done, the cpu implementation of opensubdiv will get optimized first, opengl will hopefully stay for some time on mac for blender to run on, while there will be a shift to a new lowlevel api on mac for its hardware acceleration, after that I think opensubdiv with gpu support with whatever is the chosen backend will follow.
Generally all this could be easier if Apple wouldn’t tend to force you into their custom ecosystem. The problem here is apple with not just releasing a custom lowlevel api with metal but more it was giving an uncertain future for Vulkan on Mac as a lowlevel api for quite some time and it deprecated OpenGL, thats different to Windows with DirectX and other lowlevel APIs being equally present.
So if Apple were dropping OpenGL completely and that soon that would be some kind of worst case scenario. It’s a bit of an open question how then the near future of blender on mac would be, perhaps apple kicks in and helps blender out to support metal faster, perhaps blender decides to add metal support as a backend themselves, perhaps opengl will at least be possible with a freezed version on mac for some time longer (even if its not fitting opensubdiv), perhaps everybody sells his mac and buys a pc ( a sufficiently fast complete pc system should be avaible for the price of a macs monitor stand 
). Blender falling back completely to being not gpu accelerated is performancewise no option, and I’m sure the blender team knows that.
But I think OpenGL will not disappear immediately on Mac even if its deprecated and blender will embed their planned vulkan support in the meantime and as vulkan somehow found its way on mac, its a possible solution for most parts of blender on macos too, right now just not for opensubdiv.
Opensubdiv generally has several lowlevel apis supported as backends for itself since some time it’s also supporting Metal. OpenGL is possible in Opensubdiv but not for Mac, beside that CUDA or OpenCL is possible too. So adding Metal support in Blender might be an option or stick with vulkan as its planned for windows already. Could make more sense.
It think MoltenVK having gotten open source may be a solution for this. So now it’s an option to bring blender internally to vulkan and run on a Mac gp-accelerated by Vulkan too, that way you would be half way there. We just have to hope for vulkan being supported by opensubdiv soon, or opencl-v will be there for vulkan before that.
That does seem to be the crux of the problem.
I have an iMac with AMD hardware. I’ve spent more than a few hours researching this, and I’m pretty sure you can’t get hardware (GPU) accel of any sort of operation in Blender with it. OpenGL is deprecated enough to not work, and OpenCL also not working. NOTE: this is incorrect. See below.
See this:
Looks like it’s still true today, in October 2019. From that thread, and it’s starting to look truer and truer every moment:
It is unfortunate, but that means I am really only interested in CPU optimisations for Blender, until I can figure out a Linux workstation that runs Blender well (I won’t run Windows, probably ever, but certainly at least not in the next couple years).
I poked at a System76 machine with some great nVidia hardware, but my last adventure trying to get Blender working with CUDA on my other Linux workstation leaves me battlescarred, and I’ll probably just keep suffering the Apple ecosystem unless someone can give me a Linux machine spec that definitely works for them.
Deprecating OpenGL support is not the same as dropping it. So the version shipped will be there and not blocked or removed or anything like that. That link you added is about Cycles rendering with OpenCL. Yes seems it has been deactivated, but inside Blender, completely. I didn’t know that. But OpenGL and OpenCL will are both on your Mac and yet functional.
You could load the OpenGL Extension Viewer and check that.
But it seems there are bugs that last OpenGL and or OpenCL version and no fix will ever arrive. I had hoped for you that the current version of OpenGL on Mac would be better, it’s unimportant if this situation now is Blenders or Apples fault, you can blame both, a workaround would perhaps be possible for both. But somehow blender is right that it makes no sense to put work into a version that will soon be deactivated anyhow.
I think that your workspace is running currently still with OpenGL and you just don’t know, but yeah Cycles runs on CPU. What I’ve written hasn’t really changed, it will take some time until Mac will be back on track then. Beside the fact that you not just ended with a frozen OpenGL/OpenCL version but a buggy disfunctional one for blender too. The roadmap and the way I described will stay the same. Perhaps a dev reads this and can give some insight for you what timeframe you could expect until Metal or Vulkan are supported by blender. But right now that won’t get better.
I’d have suggested to make your mac dualboot and would have installed windows in parallel, or would have even tried how well it would perform in virtualbox or alike, but as you said you won’t run Windows. To be honest I would strongly encourage you to rethink that completely. Don’t know why you argue like that. I am not really going to participate in any serious sort of OS flamewar discussion. But in short Windows is a widespread and common OS and blender should run fine out of the box. If you need blender for your work, and you think you have a quite powerful Mac in front of you, I’d call it a safe bet that you would end up with a functional version of blender that way. But all this gets a bit offtopic for this thread. I hope that helps you and makes you rethink your decision for the sake of a functional solution. If you still have a question you could send me a pm otherwise good luck.
Nothing wrong with Windows, just not for me.
I see what you mean about OpenGL etc. Yes, I have obviously some hardware acceleration, otherwise it would be unusable.
For rendering, Eevee and Cycles would be nice to have hardware support. NOTE: Eevee is hardware-accelerated, only Cycles is not.
I found some site: https://www.amd.com/en/technologies/radeon-prorender-blender Radeon Prorender for Blender add-on.
If I install that, and choose that renderer, then it looks a bit like Cycles, is faster than Cycles, but doesn’t support any of the shader nodes I use for my .blends. Heheh.
Well, I will just hope that OpenSubdiv gets faster. It is pretty slow currently. Whether that means somehow on the GPU (and cross my fingers that works on Mac) or even multi-CPU support, that I will just hope for the best. NOTE: OpenSubdiv is using multiple CPUs on MacOS.
To add a bit of technical flavour to the discussion: I turned on subdivision surface and started moving the model around with a rig in normal workspace mode. This did peg one of my four CPUs, but the other 4 CPUs were largely idle. I expect that means OpenSubdiv is a single-threaded process? NOTE: OpenSubdiv is using multiple CPUs on MacOS. This was incorrect.
This surprises me, since I thought its whole purpose in life was to take advantage of modern multi-CPU environments.
Sure may things like that be an alternative right now. But did you understand that if Mac is switching OpenGL from deprecated to dropped and the Blender Foundation hasn’t written support for Metal or Vulkan in the meantime then Eevee will also stop working completely. With Workbench I’m not sure, it’s definitely hardware accelerated too, maybe it has a software fallback, but if not…
And even if there is a software fallback the speed will definitely be lower.
Being an OpenGL engine, Eevee only uses the power of the GPU to render. There are no plans to support CPU (software) rendering as it would be very inefficient. CPU power is still helpful to handle high complexity scenes as the geometry and modifiers are still prepared on the CPU before rendering each frame.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/EEVEE
But thats up to you. I’d install Windows instead.
No it runs on all cores at least did it in my case under Windows. Sound like you’re doing it just wrong. It’s not enough to move an object with a subdivmodifier in object mode. You have to edit the controlmesh of the subdivision surface to get it calculating again.
Hahah. Doing it wrong. Actually, you’re misunderstanding what I’m doing.
Every time I click an armature control, it recalculates for the mesh that is parented to the armature. Every time I move the armature bones, the underlying mesh upon which the subdiv modifier is applied changes. It is literally impossible for Blender to achieve what happens without using the subdiv modifier, since the vertexes of the underlying mesh are changing locations in relation to each other.
Now that I’ve reworked the mesh to be all-quads, each of those recalcs went from ~6sec down to ~2sec.
And however many cores OpenSubdiv uses on Windows, it uses 1 on a 2017-era iMac. Or, more technically-precise: it goes about 1 iteration every ~2sec while I’m posing the armature, and after doing that for 30-40sec, when I look at a CPU graph of the preceding minute, it maxed out at 25% on a 4-CPU system (this may be incorrect - it might be ~50% - I’m attaching the graph).
The first blue spike (user CPU) is when I was moving the armature on the control mesh while Eevee was rendering in the 3D view. The second was when Workbench was rendering in the 3D view. As you promise, both renderers must run on the GPU, since there is no difference there.
But also, it looks like it’s using ~2 CPUs. I strongly suspect that on MacOS, OpenSubdiv does not use all CPUs. I further suspect it only uses 1 CPU, and that other CPU is used up doing other tasks involved with changing a dense mesh.
Aha! Okay, that’s why it runs in an acceptable speed here. Eevee is awesome, and I love everything about it.
Back to purely technical concerns, then, once Blender stops working on my iMac, which looks like it could happen any day now, does anyone here on this thread know what Linux hardware setups are good with Blender? As I hinted earlier, System76 have some great-looking systems, but I have no idea if Blender will actually run on them, or if I’ll be purchasing another $2,000 paperweight.
If anyone has concrete experience with Blender on Linux, I’m all ears.
Hi phil, that wasn’t meant to be insulting. My suggestion was based on this comment:
What can easily be understood wrong. Btw. the activity monitor on a mac is able to display the cores. Also I would propose that you use a simpler example if you want to discuss with others, so they can reproduce what you are talking about.
I took a cube and put two subdiv modifiers on level 4 on it and moved the top face.
As you can see under windows it causes a lot of usage on all cores. So I assume its is running with multithreading.
I have no Mac and I don’t know how the devteam did set opensubdiv up on Mac. Maybe its singlecore. That’s possible.
So give it a try to be sure:
You could post your results here, as that’s quite fitting to the topic.
But I think we really stop talking about your new pc here. There might be better places for that.
I won’t post screenshots, but you’re right. When I break it out by core, all four cores do work at nearly 100%. I just did the same thing as you, generated a simple cube with 2x subdivision on it, then moved a face around for 10-20 seconds and let the CPU burn.
The “nice and pretty” CPU graph still makes it look like at most I’m using 50% of system resources, so I’ll just chalk this up to typical Apple being Apple.
NOTE: I went back and added notes on my earlier post clarifying that GPU accel does work with most components, and that OpenSubdiv is using multiple cores on MacOS.
Hey thats good news. So currently just Cycles is running on CPU on Mac. Then just be careful if you are updating your OS. I guess when something changes with OpenGL it will coming along with an OS Update.
For that “nice and pretty” graph. Yes it doesn’t show 100% anywhere, but the two graphs there aren’t different cores. That are different kernelmodes of the os.
In version 2.82 the problem of slow OpenSubDivision will be solved? With complex characters it is unusable, you are forced to view animations without subdivisions.
With the main 3d animation software it is possible to visualize the playback with the OpenSubDivision active at incredible speeds with very heavy meshes (3 level of subdiv at 100fps!)
Also in 2.79 the playback speed was much faster.
I hope you will give priority to this problem otherwise I think it is difficult to use Blender as a serious alternative for character animations.
Actually the main task about subdivision have medium priority. When must be high priority or solve it now, basically the main problem of blender actually. I don’t know the reason to this.
If people want, you can make comments about that in developer.blender.org tasks about this subject to see the size of the problem. Maybe it cannot help because the problem is external to blender, but at least is an option.
1 Like
Because for many people, the slow undo is an even bigger problem.
1 Like
It is about prioritizing resources (time, available devs). In the end everything is important, but not everything can be done at the same time. Therefor you’ll find different issues with different priorities. It is not because something is not deemed important, it is because choices have to be made.
I understand that there are priorities, but we are talking about the most basic technology for modeling today is failing to prevent anything to do with it.
It’s like saying that the whole sculpt or the blender animation has been broken and that well, it will be fixed.
Also, as we said, this problem is also guilty of much of the problems with the undo currently.
I think this is an important task to do, new features can wait, but basic function like this should be fixed asap.
Although I’ve worked around the slow OpenSubdiv in my workflow (mainly because I’m producing stills, not animations), I kinda agree…
Subdivision is a core, fundamental tool. I’m not sure how this being broken is of anything other than “world is on fire” priority. My only way to make sense of it is that the “important Blender users” have all worked around it by having a supported GPU or something, and people with CPU-only OpenSubdiv just aren’t the intended audience for Blender?
It would make me sad, but I could understand that POV.
The devs are always aiming to improve Blender. The devs are aware of the issues, and work as hard as they can.
You are always free to discuss matters more, but I hope you realize that for this particular issue it isn’t going to make things faster, especially since awareness has been raised already for a longer time. So please let us give the devs also the working space and peace to do what they need to do to for all of us.