Get render state usage after optimization

Gaming and Visualization Technologies Visualization MDL SDK
1

I’d like to know which materials are using state::animation_time() so I can update some internal data structures. Unfortunately it appears that ITarget_code::get_callable_function_render_state_usage returns state usage before the compiler optimizes dead code. For example, any shader (like OmniPBR) which uses base::file_texture will report animation_time usage. Technically it’s used, but often the conditional is false so it gets optimized out (I hope :)). Is there a way to get the state usage after optimization? Thanks!

2

Hi,

thanks for reporting your problem!
Unfortunately, this currently isn’t possible. As soon as we generate LLVM code for some state access, we register the usage. When LLVM then inlines base::file_texture and all usages are optimized away, we don’t notice this.

We have the same problem with baking expressions, when all accesses to texture coordinates and positions are optimized away. In this case, we could just bake a constant instead of 4k texture…

I’ll add your usecase to a ticket in our backlog about getting more precise state usage info.

For now, one workaround for materials using base::file_texture() and base::tangent_space_normal_texture() could be (if you don’t use Iray), that you build an own MDL SDK with a modified src\shaders\mdl\base\base.mdl file, where you have two variants of the functions:

  1. One with the animation parameters (and the corresponding code) removed, and
  2. One where the defaults of all parameters until including the first animation parameter are removed (to make them non-optional and thus avoiding ambiguous overload resolution)

Then, if the material doesn’t support animation, the non-animation versions will be used.
But depending on the materials, you may need more variants with animation parameters…
If you don’t have full control over the used materials, that’s probably not a very reliable workaround…

Best regards
Moritz

3

Okay, thanks for confirming Moritz! We’ll see if there are opportunities to modify the materials but more precise state usage from the compiler would be great :).

Cheers,
Justin