bytedeco / javacpp-presets

The missing Java distribution of native C++ libraries
Other
2.66k stars 740 forks source link

[CUDA] Intended use of CUstreamCallback or CUhostFn #1372

Open blueberry opened 1 year ago

blueberry commented 1 year ago

I'm trying to port ClojureCUDA to JavaCPP's bindings (from JCuda). I have a challenge implementing CUDA callbacks due to how these two classes are implemented in JavaCPP's CUDA integration.

The purpose of either (CUstreamCallback is deprecated in favor of CUhostFn) is to enqueue a custom host function to be executed when the stream reaches that place in the execution queue.

In the case of JCuda, CUstreamCallback is an interface, which should implement the =call= method with the custom behavior that is then called by the CUDA engine.

For example (please treat this Clojure code as Java pseudocode):

(deftype StreamCallback [ch]
  CUstreamCallback
  (call [this hstream status data]
    (println "Hurray! status: " status)))))

Then, I can instantiate the callback objects, and provide them in =cuStreamAddCallback=. When the stream reaches the appropriate point, the status code gets printed.

In JavaCPP, these two are classes with protected constructors,. Are they intended to be inherited with the custom implementation of the call method and the constructor? I haven't been able to find any reference to these during the google search, so I'm curious whether this is working at all? Is there a reason these two are not interfaces, in which case it would be much clearer how they should be used?

I guess that the reason for making these classes rather than interfaces is that everything in JavaCPP should be a Pointer subclass. I just need clarification whether subclassing it would work in the same way, that is, whether custom reimplementation of =call= is going to work.

saudet commented 1 year ago

Yes, we just need to subclass: https://github.com/bytedeco/javacpp#creating-callback-functions

blueberry commented 1 year ago

Thanks!