Is there interest in supporting a Metal version of Cycles for MacOS?


#1

I would be interested in helping to port Cycles to MacOS using Metal (since I’ve heard OpenCL problems seem to have caused MacOS GPU support to be dropped). I’m an experienced graphics programmer, and have been implementing a lot of compute kernels on MacOS with Metal recently (though mainly for cryptography and AI). I did a lot of CUDA a number of years back. I haven’t really looked at the cycles code so far so I would need a bit of time to get up to speed (and/or some assistance).

I’m starting to get some experience with Vulkan compute as well, though that hasn’t been a priority yet. But it should pay off if a port to Vulkan is desired as well.

FYI, up until it was disabled Cycles GPU rendering on my Mac was working fine as long as I disabled the AMD GPU (the Intel one worked fine). Sorry to see it go.


#2

Hi,

there has been a similar discussion about Metal for Cycles on the mailing list. Here’s a link: https://lists.blender.org/pipermail/bf-committers/2018-December/049720.html.

In summary, this is what Ton said:

[…]
But if you want to help us with Metal:

Cycles has been designed from the ground up to support multiple graphics
APIs.
It has good Cuda and OpenCL support for that reason. Here it’s possible to
add Metal as well. Cycles code base is much smaller and much better
designed (and newer :slight_smile: than Blender code.

Why not volunteer first to help with Metal for Cycles? If that project
looks like it works well, we (and you!) also get more insight in the
complexity of having this kind of work done for Blender. Adding Metal in
Cycles will take 3-6 months of work already.
[…]


#3

Some info on the GPU compute stuff in Cycles:

Most of the kernel code is in header files that are shared between the CPU, CUDA and OpenCL versions. These headers are then included into architecture-specific files which implement the entry points and basically act as stubs around the general functions.

For example, kernel.cu defines the kernel_cuda_path_trace kernel, which just figures out which pixel to process and then calls kernel_path_trace, which is defined in kernel_path.h for all three platforms.

To be able to write platform-independent code, we use a bunch of generic preprocessor defines that then are defined to the platform-specific keywords in the kernel_compat_*.h files (e.g. ccl_device is static inline on CPU, __device__ __inline__ on CUDA and nothing on OpenCL).

Then, each platform has a host-side implementation in the form of a device_*.cpp file which implements the Device API and handles the platform-specific calls.

Therefore, for getting Metal support into Cycles, you’d need to first implement a kernel_compat_metal.h and kernel.metal, then get the Cycles kernels building (you’ll have to e.g. tweak some of the util headers I guess) and then implement a device_metal.cpp.


#4

We are interested, with the caveat that we need a developer to maintain this for the long term. The reason we dropped macOS OpenCL is that no one was maintaining it, fixing bugs or helping getting new features or graphics cards to work with it.

For me personally it is not a priority given the smaller percentage of users that would benefit from this, and Metal not being an open standard. But if other developers can do it in a way that doesn’t add too much burden to the rest of Cycles development, it would be great.

Vulkan compute as far as I know does not yet have good support for a programming language with pointer support. This makes it difficult to port the Cycles kernel in a way where we can still share code with other platforms.


#5

Ok, starting to read code. Metal has some ugliness because there isn’t a pure C binding (there’s Objective-C and Swift, which might require wrapping up and build logistics).

Great info @lukasstockner97! Are there any docs on Cycles project organization, build setup, integration into Blender, etc…? Do I need to look at anything outside of internal/cycles?

Also, is there a better place to be having these conversations?


#6

This is the right place for developer discussion.

The Cycles code docs are here. Probably you would only need to make changes in intern/cycles.
https://wiki.blender.org/wiki/Source/Render/Cycles

For build setup, you just build Blender as a whole.
https://wiki.blender.org/wiki/Building_Blender


#7

Thanks for the wiki link.

I have the build working. I guess I meant documentation on the build setup since I would probably have to get Cmake to build Metal Shading Language libraries, etc… I’ll have to read up on Cmake. Somehow I’ve managed to never learn cmake after I went from C/C++ with imake and autoconf to languages/environments that didn’t require cmake.

So, for example, where would I find how cmake knows to run nvcc (I’ve seen where it is discovered in a .cmake file, I think).


#8

There is no documentation for anything that specific. You would search the CMakeLists.txt files for “NVCC” and see how it is used.


#9

For me personally it is not a priority given the smaller percentage of users that would benefit from this, and Metal not being an open standard.

As a Mac user it’s tough reading this. Apple Metal may not be open source and Mac users may be a smaller percentage of users but Blender is meant to be cross platform. It it’s not a priority for you, is it possible Blender could be Windows only at some point?


#10

No. This is only about a feature to accelerate rendering, not about working at all, which makes the choice easier.


#11

Thanks for your reply @brecht and for the clarification.


#12

And thanks @ChuckOcheret for looking into this.

Hope you find good homes for your expertise in solutions for Blender.


#13

Believe it or not, I’m making some slow progress. Since I work mostly on a Mac (no CUDA/Nvidia or OpenCL for Blender), I have to move to my Windows box to try and understand what’s going on in CUDA code. I can build on Windows from the command line but I can’t get a Visual Studio version to build with CUDA and can’t get Visual Studio to successfully debug Blender. Next I will try to get my crummy Linux laptop up and running to see if I can understand the OpenCL version instead. Or maybe I will try to reenable OpenCL on a local Mac build since ti was working perfectly on my Intel GPU (my Metal experiments have my build-in Intel GPU about 5 times faster than the default AMD GPU for similar compute problems - e.g. a modified Hilbert R-tree as a dynamic BVH for another project). So I’m just reading code at this point (both Blender and Cycles). But I am learning.

It would help so much to be in a room with someone knowledgeable in the codebase.

Happy Holidays!


#14

I’d be happy to help on windows, but you gotta do better than ‘I can’t get it to work’ What is the problem?


#15

Lol. I wasn’t asking for help tonight. But…

There are two things I seem to be having problems with.

1 - When I build on the command line, I am able to ‘make release’ to get a version of Blender that recognizes both of my Geforce GTX 1080Ti’s. Any other target doesn’t cause the GPU’s to be recognized. So that’s a fine start. But when I build on Visual Studio (I’m a complete novice with that - well after 10 years of not using it) I can run a version of Blender that doesn’t recognize my GPUs.

2 - When I attempted to debug using Visual Studio, I was getting some other error and it wouldn’t run at all. Unfortunately, I blew away the setup to start from scratch so I need to do it over again for VS before I can tell you what the error was.

And I need to go be with family now. I’ll be back later after I get the error message again.

Merry Xmas.


#16

ayyyyyy, you’re making it hard to help… we went from ‘i can’t get it to work’ to ‘it wouldn’t run at all’ even an error message or screenshot would have helped here.

1 - Only release compiles the cuda kernels, so this is expected behavior.

2 - I’m guessing here, but it sounds like you did a debug build not build the ‘INSTALL’ project

image


#17

HI, how is work progressing with Metal. I am running a 2010 MacPro tower with a new Radeon RX580 GPU. I will be so glad when we in the backwater can get GPU rendering back.

Is there another way to get macOS support back through Vulcan? - https://arstechnica.com/gadgets/2018/02/vulkan-is-coming-to-macos-ios-but-no-thanks-to-apple/


#18

AFAIK there is no work going on top of Metal. I am a Mac user myself and I dont even care if Metal is going to be supported any time soon. Modern macs can be easily triple boot, I have my iMac running latest MacOS, Windows 10 and Ubuntu at the same time, in their own partitions natively(no VMs). Most of mac users install at least windows for games.

I am typing this on my iMac via Ubuntu. I triple boot because I am a dev myself and I like to support all 3 platforms.

The only realistic solution is for us mac users to unite and create a mini-fund for hiring a mac dev at least part time via BF of course to be part of the team and to focus on finding a solution. MacOS market share is 14% while Linux is at 2% , the rest being Windows. So there is a substantial amount of Blender mac users out there, problem is do we care ? Or are we happy using Blender from Windows/Ubuntu ? Or are we happy not having GPU acceleration of Cycles ?

There is definitely a substantial amount of Blender mac users, but overall I do not think we care so much for the reason I explained above. I would offer myself but like Brecht I like to develop features that benefit the majority of our community But I would definetly help funding, overall Apple users tend to have “deeper pockets” than your average pc user so if there is a real desire for this I do not think we will have a problem collecting the funds. Another good news is that MacOS is a very popular platform for developers. But they wont work for free.


#19

mmm interesting, maybe its time to ditch apple altogether and switch to Windows - sounds a lot easier solution for us simple users. Like most people I just want to turn my computer on and start using it, i’m not a developer just a simple consumer. I am interested thought… is Metal THAT hard to implement in Blender? Interesting that both you and Brecht could do it but are unwilling, is that because of the complexity?

My card is actually a PC GPU that also runs on macOS (Radeon RX 580). I upgraded it because it is mac compatable right out of the box (just no boot screen), has 8GB of ram and supports OpenGL 4.5, among others. It worked fine for GPU rendering in Blender for a while (and still works in 2.79!) then got dropped. When I saw someone interested in implementing Metal in Blender I saw some light on the horizon (so I thought). Anyway, its easier to just cut my losses and abandon GPU rendering for now until I can afford to upgrade.

Good thing is that the card works really well for Davinci Resolve, and other programs that use GPU acceleration and it gives me access to 4K resolution on my Samsung monitor. Thank God MacOs Open GL is good for the rest of blender, at least I can use 2.8 now.

Man that was a bit long winded!


#20

I’m still pursuing this very slowly. I’ve been sidetracked with parents in the hospital and a crunch at my startup. My initial experiments with Metal for similar workloads are promising. I get huge speedups for many activities done using Metal (vs OpenCL and especially vs OpenGL for graphical stuff). Compute stuff is tremendously faster on the internal Intel GPU but still pretty fast on the internal AMD GPU on my laptop. But I have a long way to go to really understand parts of the Blender code base. I’ve read all of the Cycles related papers pointed to in the wiki. All pretty standard stuff.

As far s Vulkan goes, I think it is doable but not by sharing as much code as I believe the Cycles developers would have hoped for. I hope to come up for air soon. Hopefully, I can get some time from some experts to answer questions.

I kinda feel like I should take a step back and make a bunch (i.e. an infinite number) of videos about Blender internals, its use of graphical techniques, computational geometry, etc…, including Cycles. But I would definitely need time from the knowledgeable devs who are pretty overloaded as far as I can tell. But I think it would be an amazing resource for the Blender community and the graphics community at large as an education tool.