update: unlock native Linux build for CMake and CPU backend only

[incertum]

Unlock native Linux build for CMake and CPU backend only.

---

Related to #258.

This PR follows the principle of making the minimal initial changes necessary to unlock native Linux builds with CMake —nothing more.

The CUDA backend for native Linux builds in CMake is something to explore afterward, knowing there are already things moving (see #258).
CC @davidkoski and @zamderax

@Joannis for follow (SSWG)

[davidkoski]

Some of the API in here has moved to memory.h and is no longer GPU specific:

int mlx_clear_cache(void);
int mlx_get_active_memory(size_t* res);
int mlx_get_cache_memory(size_t* res);
int mlx_get_memory_limit(size_t* res);
int mlx_get_peak_memory(size_t* res);
int mlx_reset_peak_memory(void);
int mlx_set_cache_limit(size_t* res, size_t limit);
int mlx_set_memory_limit(size_t* res, size_t limit);
int mlx_set_wired_limit(size_t* res, size_t limit);

we don't need to deal with it here but perhaps this needs some refactoring -- we can forward the "GPU" methods to these.

[incertum]

Thought down the road it could be nice to have GPU.swift (cross-platform) and GPU+Metal.swift (only Apple Silicon builds) files and later a GPU+CUDA.swift (cross-platform) file ... wasn't quite yet too sure how to split GPU.swift. If you believe it's ok to add into this PR, happy to do so.

[davidkoski]

I think it could be done here or left until later. I was actually thinking a Memory.swift like this:

• https://ml-explore.github.io/mlx/build/html/python/memory_management.html

Those are actually functions and properties currently on GPU but they have moved on the python side, so I think we would want to deprecate current ones and forward to the (moved) API.

I don't know if we would want a Metal.swift as it would collide with the framework. So yes, perhaps GPU+X and keep the GPU specific parts under the GPU type.

Anyway, I don't think this is critical and we could pick it up later.

[incertum]

I can take a look and let you know (I am just starting out to learn this code base). Plus we need new CI for sure -- sorry forgot about this for a second.

[davidkoski]

I wonder if we need to do something inside the default properties along these lines so that the calling process would get the default for the platform? Though I suppose this might change once this build supports CUDA

[incertum]

Agreed, and I like your suggestion to just wait this one out and see how the CUDA integration turns out to be for Linux.

[davidkoski]

Testing failed:
        'asDataCopy' is inaccessible due to 'private' protection level
        Testing cancelled because the build failed.

this is from the asMTLBuffer -- I think we can just make asDataCopy to be internal

[davidkoski]

I wonder if it is worth adding a circleci config to do the linux build?

[incertum]

I wonder if it is worth adding a circleci config to do the linux build?

Let's do GitHub workflows -- let me check on this.

We should have one YUM based and one DEB based distro to get started.

[davidkoski]

I wonder if it is worth adding a circleci config to do the linux build?

Let's do GitHub workflows -- let me check on this.

We should have one YUM based and one DEB based distro to get started.

True, I guess I should get that set up. Right now CI tests:

• swift-format (this isn't needed on the linux side as the macOS one will check all files)
• compile
• run unit tests

Compile is probably the most important as we could very easily break the linux build. The unit test one has a hook setDefaultDevice() that is actually still using the cpu. Huh. Well, anyway it has a hook that will be useful for the linux build.

[incertum]

Quick note: New plan see #294 meaning let's wait before merging this PR, but it should be considered complete in scope.