Sign in to follow this  
BearishSun

Type mismatch when writing to a 3D texture UAV

Recommended Posts

I'm getting this error when trying to dispatch a compute shader that does some writes to a 3D texture:

ID3D11DeviceContext::Dispatch: The resource return type for component 0 declared in the shader code (FLOAT) is not compatible with the resource type bound to Unordered Access View slot 0 of the Compute Shader unit (UNORM). This mismatch is invalid if the shader actually uses the view (e.g. it is not skipped due to shader code branching). [ EXECUTION ERROR #2097372: DEVICE_UNORDEREDACCESSVIEW_RETURN_TYPE_MISMATCH]

 

The (shortened) compute shader (full one here):

RWTexture3D<float4> gOutputTex;

[numthreads(8, 8, 1)]
void csmain(uint3 dispatchThreadId : SV_DispatchThreadID)
{
    float3 gammaColor = ...;
    gOutputTex[dispatchThreadId] = float4(gammaColor, 1.0f);
}

UAV format is set to DXGI_FORMAT_R8G8B8A8_UNORM.

To me this feels like it should work, write as float and the hardware converts it to an 8-bit integer (it certainly works with render targets). And if I ignore the reported error, it does in fact render fine on my machine. Also I'm pretty sure this code ran fine without errors until some recent OS/driver update (but I might be wrong).

I can't find anything about this on MSDN or elsewhere on the web. Am I forced to use "uint" in the shader and manually convert from float? Anyone has any insight?

Share this post


Link to post
Share on other sites
From MSDN:

When using typed UAV loads to read from a UNORM or SNORM resource, you must properly declare the element type of the HLSL object to be unorm or snorm. It is specified as undefined behavior to mismatch the element type declared in HLSL with the underlying resource data type. For example, if you are using typed UAV loads on a buffer resource with R8_UNORM data, then you must declare the element type as unorm float:

e.g.
RWTexture3D<unorm float4> gOutputTex;
I'm guessing the same is true for typed stores? Edited by Hodgman

Share this post


Link to post
Share on other sites

FYI you're not going crazy: this warning is new with the Windows 10 Creator's Update. It's always been required to have the "unorm/snorm" thing according to the spec, but almost nobody knew about it because it wasn't well-documented and there was no validation error for it (it has happened to work correctly on most hardware).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this