Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REVIEW] DLPack Support #913

Merged
merged 26 commits into from Mar 11, 2019

Conversation

Projects
3 participants
@harrism
Copy link
Member

commented Feb 10, 2019

This PR adds initial support for converting between cuDF DataFrame (or gdf_column) and DLPack DLTensor. https://github.com/dmlc/dlpack

Closes #912.

Initial support is for converting between 1D DLTensor and gdf_column/DataFrame.

  • Add DLPack submodule
  • Add C API gdf_from_dlpack()
  • Add C API gdf_to_dlpack()
  • Add C++ API Google Tests for above
  • Add Python cuDF DataFrame.from_dlpack() and DataFrame.to_dlpack() APIs
  • Add pytests for above

Python / Cython work will move to a separate PR. Tracked by #1046

@harrism harrism self-assigned this Feb 10, 2019

@harrism harrism added this to PR-WIP in v0.6 Release via automation Feb 10, 2019

@harrism harrism requested a review from jrhemstad Mar 6, 2019

@jrhemstad
Copy link
Contributor

left a comment

Biggest issues are just about clarifying and documenting the desired behavior of the conversion functions and trying to minimize user surprise about who owns what data and what data is safe to use.

Show resolved Hide resolved cpp/include/cudf/functions.h Outdated
Show resolved Hide resolved cpp/include/cudf/functions.h Outdated
}

// Call the managed tensor's deleter since our "borrowing" is done
tensor->deleter(const_cast<DLManagedTensor*>(tensor));

This comment has been minimized.

Copy link
@jrhemstad

jrhemstad Mar 6, 2019

Contributor

I'm confused about this.

I assume this is deleting the tensor and freeing it's allocation.

As such, as a user of this function, I would be surprised that a function to copy a DLPack tensor into gdf_columns is also deleting/freeing the tensor.

I would expect it to just do the allocation of the gdf_columns and do the copies and leave my Tensor alone, especially since it is being passed in as const I would doubly expect it to not be modified (but you're casting away the const here).

If this is desired behavior, I would be sure to add in the documentation that the tensor will be deleted and remove the const qualifier to prevent confusion.

This comment has been minimized.

Copy link
@harrism

harrism Mar 6, 2019

Author Member

The documentation on this from dlpack is limited. I think it should really be called release rather than deleter. Here is what the doc comment for DLManagedTensor says:

/*!
 * \brief C Tensor object, manage memory of DLTensor. This data structure is
 *  intended to faciliate the borrowing of DLTensor by another framework. It is
 *  not meant to transfer the tensor. When the borrowing framework doesn't need
 *  the tensor, it should call the deleter to notify the host that the resource
 *  is no longer needed.
 */

https://github.com/dmlc/dlpack/blob/5c792cef3aee54ad8b7000111c9dc1797f327b59/include/dlpack/dlpack.h#L149-L155

This comment has been minimized.

Copy link
@jrhemstad

jrhemstad Mar 7, 2019

Contributor

Ah, okay. Then I just misunderstood the semantics of the Tensor object here. It sounds like this object doesn't actually "own" any memory and calling it's deleter doesn't really delete anything important.

In that case, I think you're probably doing the right thing here.

This comment has been minimized.

Copy link
@harrism

harrism Mar 7, 2019

Author Member

I guess in the future, our deleters (in to_dlpack), will probably decrement a refcount which may lead to deletion of the memory, or may not if a reference is still owned (say by the original column).

This comment has been minimized.

Copy link
@kkraus14

kkraus14 Mar 11, 2019

Member

I believe this is causing a double free segfault for me in working with CuPy:

#0  0x00007ffff6a1f512 in free () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fff7dc92f5e in __pyx_f_4cupy_4core_6dlpack_deleter (__pyx_v_tensor=0x2b60c6c0) at cupy/core/dlpack.cpp:2778
#2  0x00007fff7dc949cb in __pyx_f_4cupy_4core_6dlpack_pycapsule_deleter (__pyx_v_dltensor=<optimized out>)
    at cupy/core/dlpack.cpp:2705
#3  0x00007ffff796d7df in capsule_dealloc (o=0x7fff7c705600) at Objects/capsule.c:261
...

This comment has been minimized.

Copy link
@kkraus14

kkraus14 Mar 11, 2019

Member

The function CuPy registers with DLPack definitely looks to free the memory:

https://github.com/cupy/cupy/pull/1082/files#diff-ddf01ff512087ef616db57ecab88c6aeR78
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp Outdated
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp Outdated
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp Outdated
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp Outdated
Show resolved Hide resolved cpp/src/io/convert/dlpack/cudf_dlpack.cpp Outdated

v0.6 Release automation moved this from PR-WIP to PR-Needs review Mar 6, 2019

harrism added some commits Mar 6, 2019

@harrism

This comment has been minimized.

Copy link
Member Author

commented Mar 7, 2019

rerun tests

@kkraus14

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@harrism I think we can ignore those 4 hung tests for now. Remnant of the CI issue.

@harrism

This comment has been minimized.

Copy link
Member Author

commented Mar 7, 2019

@jrhemstad As soon as you approve we can merge.

v0.6 Release automation moved this from PR-Needs review to PR-Reviewer approved Mar 7, 2019

jrhemstad and others added some commits Mar 7, 2019

@harrism harrism moved this from PR-Reviewer approved to PR-WIP in v0.6 Release Mar 8, 2019

harrism added some commits Mar 8, 2019

@harrism harrism merged commit 1c8a48f into rapidsai:branch-0.6 Mar 11, 2019

8 of 12 checks passed

gpuCI/cudf-cpu-prb/ubuntu16.04-cuda9.2-py3.6 Test build triggered
Details
gpuCI/cudf-cpu-prb/ubuntu16.04-cuda9.2-py3.7 Test build triggered
Details
gpuCI/cudf-cpu-prb/ubuntu18.04-cuda10.0-py3.6 Test build triggered
Details
gpuCI/cudf-cpu-prb/ubuntu18.04-cuda10.0-py3.7 Test build triggered
Details
gpuCI/cudf-cpu-prb Build finished.
Details
gpuCI/cudf-cpu-prb/changelog Build #2297 succeeded in 1.8 sec
Details
gpuCI/cudf-cpu-prb/cuda10.0-py3.6 Build #13228 succeeded in 30 min
Details
gpuCI/cudf-cpu-prb/cuda10.0-py3.7 Build #13230 succeeded in 29 min
Details
gpuCI/cudf-cpu-prb/cuda9.2-py3.6 Build #13229 succeeded in 29 min
Details
gpuCI/cudf-cpu-prb/cuda9.2-py3.7 Build #13227 succeeded in 28 min
Details
gpuCI/cudf-cpu-prb/style Build #2406 succeeded in 6.2 sec
Details
gpuCI/cudf-gpu-prb Build finished. 7837 tests run, 698 skipped, 0 failed.
Details

v0.6 Release automation moved this from PR-WIP to Done Mar 11, 2019

@harrism harrism changed the title [WIP] DLPack Support [REVIEW] DLPack Support Apr 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.