Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add API for building attribute getter free functions. #1704
Add API for building attribute getter free functions. #1704
Changes from 36 commits
d318962
1176fd4
c312d24
07bf09a
6e352b6
d3ec4fe
637275d
e4efe31
4ad7c1d
9c929bd
587fe5e
46cc9e2
9f05e03
02c4237
028aa6c
e90f4e9
0a1498d
0db9c26
6c03cda
f914eeb
1577a8d
630530f
a0dd0ed
6f68b60
651c7f9
3edffb9
697d1d3
217a238
3006684
3a0d66c
74048bc
f8e449b
c9cebdf
8c5e57c
e21087a
7c62b2f
c260dac
e72ddfb
2798354
c7971ef
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These additions are not strictly necessary for the rest of this PR to work, but it did seem to be useful to be able to query current symbol locations for a shader group inside the
build_attribute_getter
function.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To match the
AttributeSpecBuiltinArg::IsArrayLookup
, can we change@param array_lookup
to
@param is_array_lookup
Maybe we should do the same for
bool object_lookup
to
bool is_object_lookup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lgritz how "const" did you want to make these parameters? Should the copy by value be const as well, ei:
virtual void build_attribute_getter(ShaderGroup& group, const bool is_object_lookup,
const ustring* object_name,
const ustring* attribute_name,
const bool is_array_lookup, const int* array_index,
const TypeDesc type, const bool derivatives,
AttributeGetterSpec& spec);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just meant the pointer and reference parameters. Making them const:
(a) makes it clear to the reader that these are input parameters and the things they pass pointers/refs to will not be modified.
(b) allows callers to pass things to this function that they themselves received as const and would have to make awkward casts to ram it through the compiler otherwise.
I know there are some people who even declare value parameters as const, but that's not something I've ever made a habit of doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might need to add one more argument to this function to allow render developers to pass through their own information.
e.g. consider a typical wrapper class:
Some ideas:
ShaderGroup
:void Compile() { group.user_ptr = this; ... }
optimize_group(this, &group);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to have a pointer passed through to jit-compilation. We use the same shader group for multiple compiles depending on how we're going to execute it, so we'd want it to be different-per-compile call. Calls that compile as a convenient side-effect would need to have access to to it as well, so it should be piped through there.
It would also be useful in the future for things like satisfying get-texture-info calls and the like at compile time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, during shader execution,
ShaderGlobals::renderstate
exists so derivedRendererServices
can stow what ever it wants away. We are suggesting a move considering thisShaderGlobals
asExecContext
, meaning this is the context during shader execution. So it figures we need a similar context during shader compilation/JIT/OPT. WouldCompileContext
work? Nice part isCompileContext
is host only so free to be as complex as it wants. NowExecContext
contains OSL lib side stuff and Renderer stuff as well, not sure ifCompileContext
needs to be as complex or can just be an Opaque Pointer to whatever renderer passes into optimize/jit_group. I guess that is simplest to start with. If so, renderer is the supplier of it, maybetypedef void * OpaqueRendCompileContextPtr
,Although looking at that, we do have the existing host side
ShadingContext
which is already sort of a per thread thing. Should theShadingContext
move towards being aCompileContext
with a setter/getter forRendCompileContext
. And simply pass theShadingContext
through to thebool build_attribute_getter(ShadingContext &sc, ShaderGroup& group, ...) override
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I've got a few minor last-minute concerns about this addition to RendererServices, just want to be sure we're nailing down the parameters before it becomes part of the public API.
What's the difference between object_lookup being false and object_name being null? Is the object_lookup parameter needed? Same question with array_lookup and array_index.
Should any or all of those pointer or reference parameters be const?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I think I see now? The bool can be true and the pointer null in situations where the lookup will provide a value, but it isn't known at compile time?
If that's the case, then my only concern here is whether those ptrs/refs should be const.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's right, there are a few combinations, for example:
object_lookup=false, object_name=nullptr
object_lookup=true, object_name=nullptr
object_lookup=true, *object_name="obj"
The same concept applies to array_lookup/array_index and attribute_name. The convention we are setting is that nullptr is for values not known at compile time.
Agreed they should probably be const though, I'll update that.
I suppose it might be more self documenting if we switch to std::optional with C++17.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, let's make sense.
Please const-ify what makes sense, then I'm ready to merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, but the minimum c++ is 14 right now.
Short of introducing our own OSL::optional...
Maybe we should just bake it into the parameter name, to increase readability:
or embed comments to that effect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not worried about this. The documentation for the function explains it just fine. I do think it should be
const ustring*
to be extra clear that the function is not going to change what it points to. But the rest does not concern me at all.