Interfacing with FFI. Pointer access.

[Kerilk]

Dear NArray developers,

I am the developer of opencl_ruby_ffi, OpenCL bindings for ruby.
In order to interface the previous version of NArray with FFI based library I have hacked a small gem:
narray_ffi.

It mainly adds a to_ptr method to instances of NArray. This method returns an instance of FFI::Pointer with the address set as the NArray ptr field.

This allows to directly copy NArray content to GPU memory and from GPU memory to NArray.

The reciprocal functionality is also implemented as to_na and to_narray are enriched to create a NArray from a FFI::Pointer rather than a String. The ref field of the NArray struct is used to store the Pointer and mark it for garbage collection.

This allows to map arbitrary memory inside an NArray and then access this memory content from ruby.

Using this mechanisms I can allocate memory using a MemoryPointer and get an aligned slice to use for mapping on the GPU and still access it in ruby land using NArray.

Today one of my users asked if I could support the new version of NArray. While I could again hack a gem that provides those functionalities I thought that as this version of NArray is maintained and could change in the future maybe it was better to discuss the issue with you first.

Adding a dependency on FFI inside the main gem doesn't seem appealing to me, but maybe you would be interested in having a Numo gem that interfaces the new NArray with FFI. It could certainly be better implemented than my first gem if some support from the main NArray gem is provided. It could also mean easy usage of your NArray package with external C or FORTRAN scientific libraries using FFI for bindings.

Sorry for the huge post.

Best regards,

Brice Videau

[masa16]

Thank you for the important suggestion. I am busy now and I will revisit this issue a few weeks later. I think Numo::NArray becomes stable, but C-function names should be more organized.

[henrixapp]

Is this now possible?

[TApplencourt]

Can we help to implement this feature?

[ankane]

This feature would also be great for Torch-rb to mirror the functionality of PyTorch and Numpy. For maximum flexibility, it'd be great to have a way to get the address without FFI as well.

[dsisnero]

https://bugs.ruby-lang.org/issues/14722 That's why python has defined methods to describe the data shape as part of the c-api . We need something similar I believe

[dsisnero]

the Apache::Arrow project has a new c interface for the purpose of sharing column data between projects. https://arrow.apache.org/blog/2020/05/03/introducing-arrow-c-data-interface/

If Torch-rb opencl_ruby_ffi had a to_arrow method as well as this project- zero copy data sharing

" We have therefore designed an alternative which exchanges data at the C level, conforming to a simple data definition. The C Data Interface carries no dependencies except a shared C ABI between binaries which use it. C ABIs are platform-wide standards which are necessarily adhered to by all compilers which generate binaries and are extremely stable, ensuring portability of libraries and executable binaries. Two libraries that utilize the C structures defined by the C Data Interface can do zero-copy data transfers at runtime without any build-time or link-time dependency requirements."

[kojix2]

Maybe this issue can finally be overcome by making FFI support memory view?