Skip to content

OptiX 8.1 Code Differences #142

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

Open
devillove084 opened this issue Feb 6, 2025 · 4 comments
Open

OptiX 8.1 Code Differences #142

devillove084 opened this issue Feb 6, 2025 · 4 comments

Comments

@devillove084
Copy link

@LegNeato I've installed OptiX 8.1. After generating the code, there are significant differences compared to the current code. I'm wondering if it's still necessary to maintain a ray tracing sub project within the main CUDA project. Alternatively, should I consider moving it to a dedicated "rust-optix" project so that we can focus more on the relevant issues?

@LegNeato
Copy link
Contributor

LegNeato commented Mar 8, 2025

I haven't dug into this area yet, so I have no opinion 😄 . If others do, please chime in!

@trigpolynom
Copy link
Contributor

I ran into this when generating Optix v 9.0. I was going to start doing what @devillove084 suggested with a rust-optix crate but for version 9.

@jorge-ortega
Copy link
Collaborator

We're close to getting Optix 7.3 working again with the backend. It's not 8 or 9, but it's something :^)

My thoughts on spinning off the optix crates are mixed. Some things to consider:

  • Stability of the NVVM backend and cust/cuda crates.
  • Whether the spinoff will support 7 or focus on 8/9.

In the long term, it makes sense to create a separate project with its own CI to support multiple versions of OptiX, release independently, and let users choose versions based on their compute targets. For now, adding support for versions 8/9 in the existing project seems worthwhile, as it allows a shared CI to resolve issues quickly.

Supporting multiple versions will be challenging. Currently, we use feature flags and cfg_if! for different point releases of 7, but this approach may not scale well for major versions. A more elegant solution likely exists.

I'd recommend waiting for at least one more dot release before deciding to spin off. We can attempt adding support for 8/9 (or even consider dropping 7) in the current repo and reassess after the next stable release. That said, if there's strong consensus to spin off now, I'm open to it.

@LegNeato
Copy link
Contributor

Yeah, I agree. My preference would be keep the focus here / not split the very small and nascent community. If it becomes a problem or we think we are better off splitting down the road we'll deal with it then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants