# ClearUnorderedAccessViewFloat not work properly

## Recommended Posts

Posted (edited)

Hey Guys,

I have ClearUnorderedAccessViewFloat always clean my UAV (float4 StructuredBuffer) to all zeros no matter what value I passed to it.

...
FLOAT ClearVal[4] = {0.1f, 0.2f, 0.3f, 0.4f};
m_CommandList->ClearUnorderedAccessViewFloat(GpuVisibleHandle,
Target.GetUAV(), Target.GetResource(), ClearVal, 0, nullptr);
...


The UAV get cleaned all to zero, so resource bind should be correct...Please let me know if I did something stupid...

Also MSDN state "For floating-point inputs, the runtime will set denormalized values to 0 (while preserving NANs)." does that means for float clear value it has to be inside [0.f, 1.f]?

Thanks

Edited by Mr_Fox

##### Share on other sites

Have you tried multiple pieces of hardware?

Also I'm assuming it's a typo, but your example is caling ClearUnorderedAccessViewUint, not Float.

##### Share on other sites

Have you tried multiple pieces of hardware?

Also I'm assuming it's a typo, but your example is caling ClearUnorderedAccessViewUint, not Float.

Thanks for the notice, it is a typo, my engine have a wrapper around the API call, so I must copy the wrong one here...

I haven't try it on different machine yet, and will try it now.

Also I notice I do have it worked correctly on the same machine but it's worked on Texture2D<float> DXGI_FORMAT_R8_UNORM  and with FLOAT ClearVal[4] = {1.f, 1.f, 1.f, 1.f}; as clear value.

So is this function only work on texture? or even only with UNORM format?

Thanks

##### Share on other sites

Have you tried multiple pieces of hardware?

Also I'm assuming it's a typo, but your example is caling ClearUnorderedAccessViewUint, not Float.

I have tried on a GTX1080, and it's still didn't respect my clear value and zero out everything...

##### Share on other sites

I suspect it only works on typed UAVs (as opposed to raw or structured) where the type is UNORM, SNORM, or FLOAT. Looking at the D3D11 validation, I suspect we just haven't added this to the D3D12 debug layer yet. We've still got a backlog of parity work.

    if( pUAV )
{
D3D11_UNORDERED_ACCESS_VIEW_DESC desc;
pUAV->GetDesc( &desc );
if( !CD3D11FormatHelper::FloatNormTextureFormat( desc.Format ) )
{
fnSentinel.ReportMessage( D3D11_MESSAGE_ID_CLEARUNORDEREDACCESSVIEWFLOAT_INVALIDFORMAT,
"pUAV must be an UnorderedAccessView with a FLOAT, UNORM, or SNORM format." );
}
}


That'd report for raw (where the format is R32_UINT) and structured (where the format is UNKNOWN).

##### Share on other sites

Have you look at your resource state, it should be already in the uav state to call clear, also, does the clear color you use is the same as the one provide at resource creation ? Give a try to the debug layer and the gpu debug layer too for any state issues. The function definitely works with buffer, not only texture.

As a side note, denormal floating point are number so small they are handled in a particular way, you don't want them usually and if they are set to 0, you are more than happy for it usually :)

##### Share on other sites

I suspect it only works on typed UAVs (as opposed to raw or structured) where the type is UNORM, SNORM, or FLOAT. Looking at the D3D11 validation, I suspect we just haven't added this to the D3D12 debug layer yet. We've still got a backlog of parity work.

    if( pUAV )
{
D3D11_UNORDERED_ACCESS_VIEW_DESC desc;
pUAV->GetDesc( &desc );
if( !CD3D11FormatHelper::FloatNormTextureFormat( desc.Format ) )
{
fnSentinel.ReportMessage( D3D11_MESSAGE_ID_CLEARUNORDEREDACCESSVIEWFLOAT_INVALIDFORMAT,
"pUAV must be an UnorderedAccessView with a FLOAT, UNORM, or SNORM format." );
}
}


That'd report for raw (where the format is R32_UINT) and structured (where the format is UNKNOWN).

Thanks Jesse Natalie, so it seems for raw/ structured float buffer there is no convenient API call to fill with specific value? and we have to write compute shader to do the job?

Also it will be great if you guys could mention that restriction on MSDN related page, that will be great~  :P

Thanks

##### Share on other sites

Have you look at your resource state, it should be already in the uav state to call clear, also, does the clear color you use is the same as the one provide at resource creation ? Give a try to the debug layer and the gpu debug layer too for any state issues. The function definitely works with buffer, not only texture.

As a side note, denormal floating point are number so small they are handled in a particular way, you don't want them usually and if they are set to 0, you are more than happy for it usually :)

Thanks galop1n, it turn out that API call only support typed buffer... But I was curious about your side note, I know  SNORM/UNORM float are somekinda fixed point float, but didn't know more in detail, it will be great if you could elaborate on your side note :) Thanks

##### Share on other sites
Posted (edited)

Have you look at your resource state, it should be already in the uav state to call clear, also, does the clear color you use is the same as the one provide at resource creation ? Give a try to the debug layer and the gpu debug layer too for any state issues. The function definitely works with buffer, not only texture.

As a side note, denormal floating point are number so small they are handled in a particular way, you don't want them usually and if they are set to 0, you are more than happy for it usually :)

Thanks galop1n, it turn out that API call only support typed buffer... But I was curious about your side note, I know  SNORM/UNORM float are somekinda fixed point float, but didn't know more in detail, it will be great if you could elaborate on your side note :) Thanks

Yep, saw the post of Mr_Fox and it make sense now, .

For my side note, denormal is something only possible in the float ieee 754 representation, with a mantissa and exponent. It happen when the exponent would overflow to use the normal representation that make use of an implicit 1 bit before decimals of the mantissa as 1.xxx. You can read about it here https://en.wikipedia.org/wiki/Denormal_number

It is possible that the hardware take some liberty on denormals. The largest denormal is 2.225...e-308, so it is just impossible to write one even on a R32_UNORM ( unless aliasing to R32_UINT and writing the bits properly ).

Edited by galop1n