Feature/test for double behavior (#1186)

* Split out binding writing.

* Pass in the entry type.

* Take into account output type with -output-using-type
Added GPULikeBindRoot
Added dxbc-double-problem test.

* Add the dxbc-double-problem test.

2 files changed, 38 insertions, 0 deletions

diff --git a/tests/bugs/dxbc-double-problem.slang b/tests/bugs/dxbc-double-problem.slang
new file mode 100644
index 000000000..1cd3ab204
--- /dev/null
+++ b/tests/bugs/dxbc-double-problem.slang
@@ -0,0 +1,30 @@
+//TEST(compute):COMPARE_COMPUTE_EX:-slang -compute -output-using-type
+//TEST(compute, vulkan):COMPARE_COMPUTE_EX:-vk -compute -output-using-type
+//TEST(compute):COMPARE_COMPUTE_EX:-cpu -compute -output-using-type
+//TEST(compute):COMPARE_COMPUTE_EX:-dx12 -compute -use-dxil -output-using-type
+//DISABLE_TEST(compute):COMPARE_COMPUTE_EX:-dx12 -compute -output-using-type
+
+// The problem this test shows is around handling of double with dxbc on D3D12. In that combination
+// this code does not write the correct value into the first element - it appears as 0, where 
+// clearly w * pi_180 where w = 1 means the answer is not zero.
+//
+// To demonstrate the problem, renable the -dx12 -compute -output-using-type test. It will output 0 for the first item.
+
+//TEST_INPUT:ubuffer(data=[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0], stride=4):out, name outputBuffer
+RWStructuredBuffer<double> outputBuffer;
+
+[numthreads(1, 1, 1)]
+void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
+{
+    double w = double(dispatchThreadID.x + 1) * 38.63323592724938038L;
+
+    double pi = 3.14159274101257324L;
+
+    double pi_180 = pi/180;
+    double rad = w * pi_180;            
+            
+    outputBuffer[0] = rad;
+    outputBuffer[1] = pi;
+    outputBuffer[2] = pi_180;
+    outputBuffer[3] = w;
+}
\ No newline at end of file
diff --git a/tests/bugs/dxbc-double-problem.slang.expected.txt b/tests/bugs/dxbc-double-problem.slang.expected.txt
new file mode 100644
index 000000000..2cffc0e7c
--- /dev/null
+++ b/tests/bugs/dxbc-double-problem.slang.expected.txt
@@ -0,0 +1,8 @@
+0.674277
+3.141593
+0.017453
+38.633236
+0.000000
+0.000000
+0.000000
+0.000000