Adding the ability to provide a hint to the compiler, that a material is heavy to process

Development Rendering
, ,
1

Hey there,

Global shaders have the ability to provide a hint to a distributed shader mangers (UBA practically speaking), that maybe it shouldn’t attempt to group them together.

e.g:

static EShaderCompileJobPriority GetOverrideJobPriority() { // FClusteredShadingPS takes up to 11s on average return EShaderCompileJobPriority::ExtraHigh; }

We recently found the need to do this in materials (a very specific and naughty uber material was hogging up UBA for like 15 minutes on a single job), locally I’ve done this by adding this to the UMaterialInstance class:

#if WITH_EDITORONLY_DATA UPROPERTY() uint8 bSlowCompileMaterial : 1 = 0; #endif // WITH_EDITORONLY_DATA

And inside of `FMaterialShaderMap::SubmitCompileJobs`, jimmied this in:

#if WITH_EDITORONLY_DATA if (UMaterialInterface* Interface = Material->GetMaterialInterface()) { // If the material is a "slow compile" and isn't set to force-local, change it to extra-high. // This causes a distributed job to only be a single shader, rather than a group, preventing // batches from taking an excessive amount of time and hogging UBA nodes. if (Interface->bSlowCompileMaterial && (InPriority != EShaderCompileJobPriority::ForceLocal)) { InPriority = EShaderCompileJobPriority::ExtraHigh; } } #endif // WITH_EDITORONLY_DATA

I was recommended that this may be something worth suggesting, as I’m sure we’re not the only ones with cumbersome to compile materials.

Many thanks,

Alister

2

We’ve discussed a bit internally and we’re a bit hesitant to make this a property of the material data itself; basically we don’t think this is something content creators should need to care about, so having it exposed to the data that they will interact with seems the wrong approach.

That said, I’ve been theorizing some work that can be done with UBA specifically (possibly targeting release for 5.7) to eliminate the need for job batching entirely. It’s still in nascent stages but it’s a goal of mine (this whole mechanism of the job priority affecting batching behaviour has always felt a bit off to me, even though it was my idea in the first place).

My suggestion in the meantime is either to (a) just maintain your existing local modification until these changes land, or (b) perhaps consider some kind of config-file-driven mechanism to affect this behaviour instead (i.e. a list of known-slow materials in an ini file).