-
Notifications
You must be signed in to change notification settings - Fork 49
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
Rust: Creation of QFunctions from C source #1677
Comments
I think this would be a good add. Past deciding upon little interface details, I think the bulk of the work would be
|
Good to hear! Questions to your points:
|
|
|
The JiT backends know Q and that is a compile time constant for them. The number of components is compile time constant from the basis. I'm not sure I follow why you wouldn't be able to write the functions you would possibly want to use ahead of time? If it's not possible to do that for some reason, you could make a Rust function to write brand new QFunction source files I suppose? |
May not be helpful, but the way we get around this in HONEE and the fluids example is to have qfunction helper that's flexible and then have a series of qfunctions that set the number of components as a compile-time constant. Then we have a function that will return the appropriate qfunction for the number of components desired. |
You're right, in hindsight I don't see a problem for these kinds of constants. My concern came primarily from the way it is done with the Rust closures.
The only (but realistic) example I have at this time would be specifying a function f(x,y,z) to project on the finite element space as part of a configuration file that is read at runtime. Without touching the QFunction source at runtime in one way or another I don't see a way to inject a custom function at runtime. Emitting or modifying a C source file at runtime would be totally fine for that too - I was just curious as to whether the libCEED backends normally expect a file or just a string that holds the C source code.
Interesting to see, thanks for this! |
Maybe something along the lines of pub fn create_from_c_src(
ceed: &crate::Ceed,
vlength: usize,
path: std::path::Path,
user_f: fn(*mut ::std::os::raw::c_void, bind_ceed::CeedInt, *const *const bind_ceed::CeedScalar, *const *mut bind_ceed::CeedScalar) -> ::std::os::raw::c_int
) -> crate::Result<Self> {
// ...
} It looks like Rust would really prefer we compile ahead of time. Maybe the |
|
The host QFunction function pointers are compiled ahead of time for every backend. We don't have a way for CPU backends to do JiT right now. If you want to only use JiT functionality, you'll lose all testing on CPU backends. I don't know what you mean by 'pipeline'? The standard C interface for creating a QFunction accepts a host function pointer. Is that what you're asking? |
For C (and CPU), the header is included in a corresponding |
I suppose my question does not really apply as I thought it does for AoT and it is much simpler than I expected. The original thought as to why I was interested in creating QFunctions from C source was to allow usage of the GPU or more generally JiT backends, since the If support should be for both JiT and non-JiT backends, then the user is required to:
whereas supporting only JiT backends would only require passing the path and would not require dealing with compiling C files as part of the Rust build process. Would it make sense to cut some of the complexity from the initial implementation and support only JiT backends to close the capability gap and leave support of |
I'd really, really rather not skip on CPU features.
I'm not sure exactly what this part means? There's a single allowable function signature that the user can write and we should be able to specify it? |
I think |
Fair enough!
Looking at your porposed interface, the user needs to pass a |
If |
I'm rusty on my Rust, but can we typedef that fn type? |
A type alias could work for just the type: Though this is not particularly helpful for the user since the user needs to write a signature that includes the function name and argument names (argument names may just be
I suppose that it could possibly be done with a macro. |
Perhaps the larger problem is informing |
There could be a Note that the general situation is similar to |
Hi,
In #1621, it was mentioned that functionality to create QFunctions from C source through the Rust bindings would be reasonably straightforward to implement. This would allow usage of the JIT backends when using the Rust bindings from what I can tell. (With this type of QFunction creation, is it still possible to run non-JIT on CPU?)
First, I would like to hear some general opinions on including this as a feature next to QFunctions from the gallery and QFunctions from closures.
Secondly, given that this probably not high on your priority list, I'm happy to contribute to this (with some guidance) if that would be welcome/helpful.
The text was updated successfully, but these errors were encountered: