Should I enable r.Vulkan.Allow16bitOps?

Development Rendering
, ,
1

.

[Attachment Removed]

2

Steps to Reproduce

Hi,

I stumbled over the “r.Vulkan.Allow16bitOps” cvar. It says that it speeds up TSR. So are there any known issues?

We are using Vulkan and I was just wondering why is it not on by default? Maybe a bigger memory footprint?

Thanks for the help!

[Attachment Removed]

3

Hi Jan!

I think technically r.Vulkan.Allow16bitOps is enabled at head, but regardless of what is set there you are correct that we end up disabling it for TSR:

static ERHIFeatureSupport Supports16BitVALU(EShaderPlatform Platform)
{
	// UE-254365
	if (IsVulkanPlatform(Platform))
	{
		return ERHIFeatureSupport::Unsupported;
	}
 
	return FDataDrivenShaderPlatformInfo::GetSupportsRealTypes(Platform);
}

The reason we had turned it off is because of compilation issues in SPIRV. You’ll see that we’ve made progress lately (with the addition of the PLATFORM_USES_SPIRV_RESOURCE_TYPES in TSRCommon.ush), but we still have a bit more work to do before we turn it on.

Another issue we’re trying to tackle is the fact that the TSR shaders are among the longest to compile on editor startup. Ideally we’d leave bSupportsRealTypes to RuntimeDependent in the DDPI so that both are available, but it means we’d need to compile both regular and 16bit variants of the shaders once enabled (essentially doubling the number of shaders).

We plan to tackle this right after the next release at this point… If all goes well, we’ll update our shader compiler, fix whatever remains that needs fixing, and potentially use specialization constants to reduce the number of shaders that needs to be compiled (to make up for the new permutations we’d be adding with 16bit).

Cheers,

JN

[Attachment Removed]

4

Hi,

thanks for the clarification!

[Attachment Removed]