Accessing shader network parameters in OptiX

[Declan Russell]

Hi All,

Currently, as far as I am aware there doesn't seem to be a way of getting the address of a parameter in a shading network in OptiX using the public OSL API. This can be useful for reading output parameters from OSL shading networks to pass on to other things. Currently you're pretty much forced to use Ci as the output of a network.

In traditional CPU OSL this can be achieved by simply searching for the symbol of the parameter in a group using ShadingSystem::find_symbol() and then getting the address of this symbol via ShadingSystem::symbol_address(). In OptiX you don't have access so such interfaces at execution time and presumably implementing such a system on the GPU would likely be sub-optimal as I think find_symbol() uses string matching which isn't a good fit for the GPU. So what do we have access to on the GPU? Well we have a memory pool in which we pass to the callable programs which serve as the storage of the GroupData struct. This struct stores all the parameters and various other data. So we simply need to have some offset into this memory pool computed ahead of time to index into this memory pool to the correct address. Personally I couldn't find any ways to compute this offset easily using the public OSL API. The only way I could think to do this within the API would be to try and reconstruct how OSL is going to create the GroupData struct based on prior knowledge of the shading network. This isn't super reliable and could break if newer versions of OSL change how the GroupData struct is computed.

This can be solved easily however if you start using the private headers from OSL. You can simply cast a ShaderSymbol to a pvt::Symbol from osl_pvt.h. The pvt::Symbol class has this offset readily available and can be accessed via Symbol::dataoffset(). So I guess my questions are,

1. Is there a way to do this with the public OSL API that I am missing?

2. If there isn't a way to do this currently in the public OSL API can we add one? I would see this API being similar to the ShadingSystem::symbol_address() function but instead being something like ShadingSystem::symbol_offset().

Cheers,

Dec

[Larry Gritz]

I have a patch I'm working on, which I hope to post as a PR by the end of this week, that addresses the output issue. The approach I've taken is that you explicitly declare the renderer or group outputs including their type and "offset" within an output data block, and when you execute a shader you pass the pointer to the start of the output block. Code is generated as part of the shader that copies the right variables into the designated output buffers. No more retrieving them symbol by symbol at all.

Let's put the rest of your email on hold until you see how that works, and then we can all think about whether it covers all the cases we care about, and return to the idea of exposing something akin to the Symbol info only if it's necessary.

-- lg

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To post to this group, send email to osl...@googlegroups.com.
Visit this group at https://groups.google.com/group/osl-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/7ed9b759-1ca0-43ca-9494-a08b893df6e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Declan Russell]

Sounds good! Looking forward to it :)

On Wednesday, May 15, 2019 at 4:56:30 PM UTC+1, Larry Gritz wrote:

I have a patch I'm working on, which I hope to post as a PR by the end of this week, that addresses the output issue. The approach I've taken is that you explicitly declare the renderer or group outputs including their type and "offset" within an output data block, and when you execute a shader you pass the pointer to the start of the output block. Code is generated as part of the shader that copies the right variables into the designated output buffers. No more retrieving them symbol by symbol at all.

Let's put the rest of your email on hold until you see how that works, and then we can all think about whether it covers all the cases we care about, and return to the idea of exposing something akin to the Symbol info only if it's necessary.

-- lg

On May 15, 2019, at 7:24 AM, Declan Russell <dec...@solidangle.com> wrote:

Hi All,

Currently, as far as I am aware there doesn't seem to be a way of getting the address of a parameter in a shading network in OptiX using the public OSL API. This can be useful for reading output parameters from OSL shading networks to pass on to other things. Currently you're pretty much forced to use Ci as the output of a network.

In traditional CPU OSL this can be achieved by simply searching for the symbol of the parameter in a group using ShadingSystem::find_symbol() and then getting the address of this symbol via ShadingSystem::symbol_address(). In OptiX you don't have access so such interfaces at execution time and presumably implementing such a system on the GPU would likely be sub-optimal as I think find_symbol() uses string matching which isn't a good fit for the GPU. So what do we have access to on the GPU? Well we have a memory pool in which we pass to the callable programs which serve as the storage of the GroupData struct. This struct stores all the parameters and various other data. So we simply need to have some offset into this memory pool computed ahead of time to index into this memory pool to the correct address. Personally I couldn't find any ways to compute this offset easily using the public OSL API. The only way I could think to do this within the API would be to try and reconstruct how OSL is going to create the GroupData struct based on prior knowledge of the shading network. This isn't super reliable and could break if newer versions of OSL change how the GroupData struct is computed.

This can be solved easily however if you start using the private headers from OSL. You can simply cast a ShaderSymbol to a pvt::Symbol from osl_pvt.h. The pvt::Symbol class has this offset readily available and can be accessed via Symbol::dataoffset(). So I guess my questions are,

1. Is there a way to do this with the public OSL API that I am missing?

2. If there isn't a way to do this currently in the public OSL API can we add one? I would see this API being similar to the ShadingSystem::symbol_address() function but instead being something like ShadingSystem::symbol_offset().

Cheers,

Dec

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to osl...@googlegroups.com.

To post to this group, send email to osl...@googlegroups.com.
Visit this group at https://groups.google.com/group/osl-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/7ed9b759-1ca0-43ca-9494-a08b893df6e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com