Create MtlArray using memory allocated by Array

[christiangnrd]

Feedback on implementation, interface, tests, etc. is welcome.

Closes #62

[christiangnrd]

Maybe a check to see if a pointer is page-aligned and throw otherwise? And then for unsafe_copyto! it could fallback to the old implementation if the pointer is not page-aligned?

[tgymnich]

In theory the function is already unsafe. Might as well be up to the user to check? Not sure.

But yeah either documenting or asserting is a good idea.

[christiangnrd]

I believe that this code works in MacOS 14.4 but not MacOS 13.x. For some reason, on 14.4, alloc_buffer_nobytes always works, even if the array is not page-aligned, while in MacOS 13, it always returns a null pointer.

Does anyone have any ideas as to why?

[maleadt]

FWIW, https://developer.apple.com/documentation/metal/mtldevice/1433382-newbufferwithbytesnocopy still mentions that the pointer has to be page-aligned.

[christiangnrd]

Apparently the array/buffer size also has to be divisible by 4096 to work in MacOS 13.

https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/MemoryAlloc.html#//apple_ref/doc/uid/20001881-99117

[maleadt]

I think we always have to enforce pointer and buffer alignment:

pointer

    A page-aligned pointer to the starting memory address.
length

    The size of the new buffer, in bytes, that results in a page-aligned region of memory.

Even though it seems to work on macOS 14, it does seem to violate the docs. I'll push a commit, if you don't mind.

[maleadt]

@christiangnrd I tightened the check as mentioned above, and also simplified the implementation a little: determining nocopy within unsafe_copyto so that it doesn't have to be passed as a kwarg that doesn't really make much sense IMO (because it's about the temporary buffer, which is an implementation detail to the unsafe_copyto! caller).

[christiangnrd]

All the changes you made seem like improvements to me.

[maleadt]

Thanks!