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

Re-remove device decoration from some osl_ functions #1951

Merged
merged 1 commit into from
Mar 2, 2025

Conversation

lgritz
Copy link
Collaborator

@lgritz lgritz commented Feb 27, 2025

Recent PR #1852 (Free functions for texturing, point clouds, and trace) added host/device decorations to certain osl_ functions that previously were replicated in OptiX-based renderers. This means that now the ones in those renderers will be seen as duplicate symbols.

The more clear intent that we'd like to work towards is that all the osl_ functions are meant to be "internal" to the liboslexec or the bitcode it provides, and the rs_ functions are the customization points that the renderer is expected to supply.

Except... a bunch of the osl_ functions that set parameters for subsequent texture and trace calls do not yet have rs_ customization points. So we're actually not quite ready to change things.

To unbreak, then, this PR removes the __device__ decorations (so they are again safe/expected for GPU renderers to override them). To keep testshade/testrender working, we add copies of them to testshade/testrender specifically.

Like I said, eventually we'll add rs_ customization points, and at that point, we'll truly expect the osl_ functions to be only supplied by oslexec itself and not the renderers.

Recent PR 1852 (Free functions for texturing, point clouds, and trace)
added host/device decorations to certain `osl_` functions that
previously were replicated in OptiX-based renderers. This means that
now the ones in those renderers will be seen as duplicate symbols.

The more clear intent that we'd like to work towards is that all the
`osl_` functions are meant to be "internal" to the liboslexec or the
bitcode it provides, and the `rs_` functions are the customization
points that the renderer is expected to supply.

Except... a bunch of the `osl_` functions that set parameters for
subsequent texture and trace calls do not yet have `rs_` customization
points. So we're actually not quite ready to change things.

To unbreak, then, this PR removes the `__device__` decorations (so
they are again safe/expected for GPU renderers to override them).
To keep testshade/testrender working, we add copies of them to
testshade/testrender specifically.

Like I said, eventually we'll add `rs_` customization points, and at
that point, we'll truly expect the `osl_` functions to be only supplied
by oslexec itself and not the renderers.

Signed-off-by: Larry Gritz <[email protected]>
@chellmuth
Copy link
Collaborator

LGTM!

@lgritz lgritz merged commit 0043bf9 into AcademySoftwareFoundation:main Mar 2, 2025
26 checks passed
@lgritz lgritz deleted the lg-rs branch March 2, 2025 05:08
lgritz added a commit to lgritz/OpenShadingLanguage that referenced this pull request Mar 2, 2025
…Foundation#1951)

Recent PR 1852 (Free functions for texturing, point clouds, and trace)
added host/device decorations to certain `osl_` functions that
previously were replicated in OptiX-based renderers. This means that
now the ones in those renderers will be seen as duplicate symbols.

The more clear intent that we'd like to work towards is that all the
`osl_` functions are meant to be "internal" to the liboslexec or the
bitcode it provides, and the `rs_` functions are the customization
points that the renderer is expected to supply.

Except... a bunch of the `osl_` functions that set parameters for
subsequent texture and trace calls do not yet have `rs_` customization
points. So we're actually not quite ready to change things.

To unbreak, then, this PR removes the `__device__` decorations (so
they are again safe/expected for GPU renderers to override them).
To keep testshade/testrender working, we add copies of them to
testshade/testrender specifically.

Like I said, eventually we'll add `rs_` customization points, and at
that point, we'll truly expect the `osl_` functions to be only supplied
by oslexec itself and not the renderers.

Signed-off-by: Larry Gritz <[email protected]>
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

Successfully merging this pull request may close these issues.

2 participants