[SM 6.10][LinAlg] Fixes float truncation and coordinate calculation in LinAlg exec tests

[anupamachandra]

Float fill values streamed into compiler defines (e.g. -DFILL_VALUE=42) were losing their decimal point, causing HLSL to interpret them as integers. Add std::showpoint to all stringstreams that format float values into -D defines so they always emit a decimal point. Fixed this in:
SplatStore_Wave_16x16_F16
MatMatMul_Wave_16x16x16_F16
MatMatMulAccum_Wave_16x16x16_F16
MatAccum_Wave_16x16_F16
StoreMemory_Wave_16x16_F16
AccumulateMemory_Wave_16x16_F16

Also fixes the computation of the flatenned coordinate in ElementAccess_Wave_16x16_F16.

[jenatali]

I ran into this with WARP too before seeing this text in the DXIL section of the spec:

Fills a matrix with a scalar value. The scalar's type does not need to match the matrix component's type, a type conversion is applied following the rules documented in the Conversions section.

So even if it is a 42 integer value, the driver should be converting it to a float in the fill instruction anyway.

[tex3d]

That sounds right, however shouldn't we also suffix the value with F to ensure that it is always interpreted as float in the shader? Otherwise, there might be a difference depending on conforming literals (pre-HLSL 202x).

Suggested change

	ExtraDefs << std::showpoint << "-DFILL_VALUE=" << FillValue;
	ExtraDefs << std::showpoint << "-DFILL_VALUE=" << FillValue << "F";

[tex3d]

Good catch. It sure can be confusing for x to be row and y to be column, but makes most sense in context.