We had a duplicate request #3123 Responding to that here to avoid a scattered conversation.

Based on what I, personally, have checked out from Metal specification and documentation, it seems like Metal has most of the required ingredients to be a valid backend of ArrayFire. Having said that, Metal is tied down to Apple platform where as all of our current backends are cross platform. Apart from, I am not sure if we can achieve feature parity with our current backends which is very important for us. To figure out if such feature parity is possible, more detailed analysis of metal framework needs to be carried to understand how much of our API can be supported right away.

Regarding #3123 (comment) @BA8F0D39 , I personally don't know what's the future of Metal on Apple platforms. But what you said about cross-platform nature, that is true. Regarding Vulkan being a compute successor to OpenCL, I don't think that is true. In fact, OpenCL far more flexible and useful API than Vulkan from scientific computing perspective. Today's Vulkan is at best, OpenGL compute shaders on steroids - that's what I gathered from it's specification.

@atolkachiov As far as, the decision to provide a Apple only backend for ArrayFire, we haven't looked into it yet. Above all, from the language stand point, as @BA8F0D39 has pointed out, ArrayFire is written in C++ with C, C++, Rust, Python and other APIs. Having to write an entire code base in totally different language is a gargantuan task.

Putting together all of the above information, I feel like ArrayFire API for Metal is separate product all together.

Uh oh!

Metal Backend #2878

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions