Texture sampling in OSL

[caojia...@gmail.com]

Hi,

I'm not quite familiar with OSL implementation. I got a question when I read the interface to sample texture, it seems that instead of acquiring a handle ( like a GPU shader ), OSL uses string to identify the textures.

texture (string filename, float s, float t, ...params...)

Above is an interface to sample a texture in OSL. My concern is that do we need to process the string to acquire the handle every time we access a texture? I also saw some cache stuff in TextureSystem, does it help to mitigate the problem.

And the other very important question that I have is that, do we have an example demonstrating how to support texture?

Thanks

Jiayin

[caojia...@gmail.com]

Answering it by myself in case someone else has the same question.

OSL will cache the texture handler ( a pointer where the system knows how to interpret how to retrieve pixel information ) during compilation.

It will call 'get_texture_handle' to expose a chance for an external system to load the texture from file and create the texture_handle.

There is no hash table accessing if texture handle is available, which means the texture fetching overhead is not gonna be very high because of hash table access.

[Larry Gritz]

Sorry for the delay, your first message arrived shortly before the end of the work day on Friday, and you had found your own answer before I got in to the office on Monday.

Your analysis is correct. The reliance on "strings" should have no performance impact on the execution of shaders in the vast majority of cases.

-- 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.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[caojia...@gmail.com]

Hi Larry,

Thanks for replying to me.

Choosing Open shading language for my toy ray tracer is easily one of the best decision I have ever made for my ray tracer.

I fully replaced my old material system with a brand new OSL compatible one and gained quite a lot of flexibility by supporting it.

Thanks for your guys' great work!!

My two cents w.r.t the texture sampling. Could it be better to introduce a new concept, like texture object. in OSL so that there is a way to change texture right before shader execution? I think the gain is as following:

• Imagine I have a shader group with 10 shader layers loading textures, each shader layer has two possible textures to load. I will have to build 1024 shader group to fully support it. ( I could be wrong about this one though )
• The current implementation kind of binds the image loading process with the shader compilation together because TextureSystem receives a notification during shader compilation and the compilation process requires a pointer to be returned before it ends to fully optimize the texture sampling method to avoid parsing strings. There are two limitations that I see
• Texture loading can only be from a file. Other streaming methods may not work directly with the current implementation.
• Texture loading has to happen in the middle of shader compilation.

There could be several ways to work around the second limitation by loading textures beforehand and use a string as the name of the texture to identify it as long as the render knows how to interpret the string, it should be fine. That way, we can decouple texture loading and shader compilation. But it sounds like more of a 'work around' to me.

If we support a concept like texture object, this will be easier to be understood by graphics programming coming from realtime rendering industry. The only cache I see here is one level of memory indirection, potentially causing an instruction cache miss on CPU side, but the gain is dynamically switching texture objects in a shader without re-compiling.

On Tuesday, 9 April 2019 01:28:38 UTC+8, Larry Gritz wrote:

Sorry for the delay, your first message arrived shortly before the end of the work day on Friday, and you had found your own answer before I got in to the office on Monday.

Your analysis is correct. The reliance on "strings" should have no performance impact on the execution of shaders in the vast majority of cases.

-- lg

On Apr 7, 2019, at 11:46 PM, caojia...@gmail.com wrote:

Answering it by myself in case someone else has the same question.

OSL will cache the texture handler ( a pointer where the system knows how to interpret how to retrieve pixel information ) during compilation.

It will call 'get_texture_handle' to expose a chance for an external system to load the texture from file and create the texture_handle.

There is no hash table accessing if texture handle is available, which means the texture fetching overhead is not gonna be very high because of hash table access.

On Saturday, 6 April 2019 08:09:16 UTC+8, caojia...@gmail.com wrote:

Hi,

I'm not quite familiar with OSL implementation. I got a question when I read the interface to sample texture, it seems that instead of acquiring a handle ( like a GPU shader ), OSL uses string to identify the textures.

texture (string filename, float s, float t, ...params...)

Above is an interface to sample a texture in OSL. My concern is that do we need to process the string to acquire the handle every time we access a texture? I also saw some cache stuff in TextureSystem, does it help to mitigate the problem.

And the other very important question that I have is that, do we have an example demonstrating how to support texture?

Thanks

Jiayin

--
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.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Olivier Paquet]

Le lundi 8 avril 2019 20:57:46 UTC-4, caojia...@gmail.com a écrit :

My two cents w.r.t the texture sampling. Could it be better to introduce a new concept, like texture object. in OSL so that there is a way to change texture right before shader execution? I think the gain is as following:

• Imagine I have a shader group with 10 shader layers loading textures, each shader layer has two possible textures to load. I will have to build 1024 shader group to fully support it. ( I could be wrong about this one though )

No, you can definitely do it with a single group. There are a few ways to go about it. 

• The current implementation kind of binds the image loading process with the shader compilation together because TextureSystem receives a notification during shader compilation and the compilation process requires a pointer to be returned before it ends to fully optimize the texture sampling method to avoid parsing strings. There are two limitations that I see

Not quite. As far as I know, the optimizer attempts to get a handle when the group is assembled but that's not always possible. The texture name can be generated at runtime with format(), obtained from an attribute, a parameter which is not locked, etc. In those cases, the string based lookup is performed on every run. That's why RendererServices::texture() receives both a file name and a handle (see https://github.com/imageworks/OpenShadingLanguage/blob/master/src/liboslexec/rendservices.cpp#L162 )

• Texture loading can only be from a file. Other streaming methods may not work directly with the current implementation.

Not at all. The renderer can interpret the string however it likes. It can refer to something from the network. It can point to memory in a different application. You could even encode the texture itself in the string if you wanted to.

 

Olivier