Saturday, January 19, 2013 5:19 AM
The following file fail to compiler under the compiler version I mentioned. (The one shipped with Visual Studio 12)
//hlsl startcbuffer ConstantBuffer00 : register(b0)
RWStructuredBuffer<uint> BufferAtomic : register(u1);
Texture2D tex : register( t0 );
SamplerState sam : register( s0 )
Filter = MIN_MAG_MIP_LINEAR;
AddressU = Wrap;
AddressV = Wrap;
float4 col : COLOR;
float4 main(PSInput input) : SV_Target
uint k = (uint)(input.col.y);
InterlockedAdd( BufferAtomic[k], (uint)(input.col.r) );
if (cb00[k].x == 0)
return tex.Sample( sam, input.col.rg );
Compiling command line:
fxc /Tps_5_0 test.fx
Error info:test.fx(29,12-42): error X3662: gradient operation uses a value that may not be defined for all pixels (in ps_5_0 UAV loads can not participate in gradient operations)
test.fx(27,8-15): error X3662: this variable dependent on potentially UAV-related data: BufferAtomic
This error information is wrong. The same hlsl can compile successfully with fxc shipped in June 2010 DirectxSDK.
I want to confirm this is a HLSL compiler bug. And I also want to know when the potential fix will be available. Since such compiler is embedded in WindowsSDK/Windows8, the public fix will only be shipped to new SDK or windows8 update? (I am using windows7, so I have such concern.)
I do not need workaround, since I can use old version compiler to offer binaries instead.
Monday, January 21, 2013 10:27 PM
The D3DCompiler is serviced through Windows SDK releases. It's not part of the Windows OS at all. Any updates would therefore be released through a future Windows SDK release.
Tuesday, January 22, 2013 1:32 AM
Thanks for the info!
We still want to confirm it to be the HLSL compiler bug, and hope MS to fix when next version WindowsSDK is release.
Tuesday, January 22, 2013 8:05 PM
This issue has been filed.
- Marked As Answer by Tango1979 Wednesday, January 23, 2013 6:49 PM
Wednesday, January 23, 2013 6:48 PM
We will use compiled MS tokens temporarily.