api: extend TypeDesc and ParamType to represent ustringhash #3915
Conversation
I think it will be handy to be able to have ParamList contain ustringhash and have a TypeDesc that can describe it explicitly. Also remove some long-dead code from paramlist.cpp. Signed-off-by: Larry Gritz <[email protected]>
|
Anybody object to this? |
|
As far as having TypeDesc support more types goes, this seems fine. I'm pretty sure this change covers all the existing locations where types are processed and there's passing test coverage too. However, I don't have much experience with ustrings/hashes in general beyond knowing they exist and needing to be aware of them in certain places within the Cycles codebase. Do you already have a scenario in mind where this change will allow things to be more performant, or more convenient, than before? |
|
@jessey-git Yes, the use case is for OSL on GPU, where the ustring representation (which is a pointer to the characters of the canonical copy of the string that exists in the internal ustring table) is not a good representation on the GPU because (a) it's not a valid pointer to any memory accessible from the GPU, and (b) the pointer representation is not guaranteed to be the same from run to run (since it's just what you got from an allocation), which means it really can screw up the OptiX compilation cache. We want a GPU-side representation for string token that is constexpr (compile-time evaluatable from the string literal) and guaranteed the same on all platforms and from run to run. The ustringhash is just a different representation of the same ustring that has those properties, and helps to support the next big OSL release which uses ustringhash extensively. |
|
Ah, I see. That context is really great to have, thanks for explaining! No objections here. |
I think it will be handy to be able to have ParamValue contain ustringhashes and have a TypeDesc that can describe it explicitly.