Issues about OpenGL Interoperability and contributions

[Garden_eel]

I'm interested in using the OpenGL Interoperability via this crate for rust, since it works literaly and more reliable than competitors afaic. However, I've encountered some confusion during practice and have a few issues to raise:

Is that all the functions and modules of the driver API fully capable?

I'm wondering if OpenGL Interoperability is implemented in a less intuitive way, similar to how Vulkan Interoperability is implemented through the external memory module.

How to construct the module?

If the response of first issue is negative, I'm interested in contributing to the crate to add the module I need if it is within my capabilities, since the contribution guidence provided on issue #156 seems like easy enough. On further exploration, the mismatch of modules between Documents and cudarc crate puzzled me on the principle/designed pattern of the cudarc. I'm uncertain about how to correctly add functions/module to cudarc. Could you clarify the principles/design patterns you followed when building the module?

I appreciate your time and look forward to your response.

[Corey Lowman]

Could you clarify the principles/design patterns you followed when building the module?

Basically there's three levels of API to add to cudarc for each nvidia "module":

1. sys - in the rust ecosystem, any crate or module with "sys" in the name generally contains extern "C" bindings. So this level of the cudarc just binds to the relevant nvidia functions/methods. This is generated by using bindgen.
2. result - Since all the calls in sys are just extern C calls, they aren't "rustified". Basically they don't return Result and we want them to. So the result level adds an Error enum and wraps all the sys calls with functions that return Result. Where possible they also make certain calls "safe"
3. safe - Since ultimately we want to provide a safe api as much as possible around the unsafe extern calls, this final level aims to provide that. Most of the unsafe-ness from sys/result levels come from handling double free/use before allocation/null pointers/etc. So at this level we just take advantage of rust ownership/results to handle all of that.

sys/result should stick pretty closely to the nvidia APIs, and the safe level should still aim to be as thin as possible.

Hopefully this helps!

[Garden_eel]

Thanks a lot, the reply is concise and helpful. :)