NOT an issue - Performance question

[Pjbomb2]

Hello! Sorry for not using the issues tab for an issue, but I wasnt sure of a better way to ask this; Do you have any ideas or suggestions for optimizing the pipeline? I am integrating the pipeline into my unity pathtracer(so dealing with HLSL(/SLANG compile path)) and I do notice it is significantly slower than my previous disney BSDF(like 50% at times), which I was trying to get away from due its inaccuracies with the pdf calculations.
Also, at least in my experience, with unity/HLSL with this implementation, I do notice that the non-texture mode for energy compensation is completely unusable and renders the diffuse completely black, as indexing into such long arrays dynamically just doesnt compile correctly/refuses to actually sample. Switching to the texture mode solves this ofc.
Thanks! And sorry for the trouble.

[peterkutz]

Hello @Pjbomb2 , thanks for creating this issue. Since we don't have any other channel for correspondence right now, GitHub issues are probably the best avenue for questions and discussions.

Regarding optimizing the pipeline, to clarify, are you referring to pipeline creation time as opposed to runtime performance of the BSDF? If so, you might be seeing reduced performance due to the sheer amount of code and number of features. You can use the included specialization constants macro to completely disable unused parts of the code at shader compilation time, and then use the appropriate version of the shader at runtime based on the material properties. Have you tried that? This is the macro:

// Default specialization-constant hook. Override before including any OpenPBR
// header if your renderer provides its own specialization constant pipeline.
#ifndef OPENPBR_GET_SPECIALIZATION_CONSTANT
#define OPENPBR_GET_SPECIALIZATION_CONSTANT(name) true
#endif

If you haven't already, you would override that with your own implementation before including openpbr.h. You can find all details in the README and in openpbr_settings.h. Note that some heavy features don't have corresponding specialization constants yet.

Regarding the non-texture mode, that's good to know. We do have a working Slang integration, however it's also using the texture mode, so we may want to introduce tests to ensure that the non-texture path is exercised and maintained. Non-texture mode is not expected to be efficient, but it's interesting that it's not working at all.