For an if block
if (cond)
{
<then_block>
}
else
{
<else_block>
}
We flatten it by first replacing any store instruction `v[[k]] = x`
in the then_block with the following:
1: load(v[[k]])
2: cond ? x : @1
3: v[[k]] = @2
Similarly, we replace any store instruction `v[[k]] = x` in the
else_block with the following:
1: load(v[[k]])
2: cond ? @1 : x
3: v[[k]] = @2
Then we can concatenate <then_block> and <else_block> together and
get rid of the if block.
Currently, on what we consider normalized vsir, destination write masks
are not relative to the signature element's mask, even though source
swizzles are. Also for most instructions, the source swizzles are masked
by the destination write mask, as given by vsir_src_is_masked().
The DXIL parser however, is not derelativizing the destination write
masks for system value signature elements, so we fix that to make it
consistent with how other front-ends are handled.
For instance, when the test introduced in commit
ca5bc63e5e is compiled to DXIL using DXC,
and then parsed using vkd3d-compiler, we get the following store
instructions:
vs_6_0
.input
.param POSITION.xyzw, v0.xyzw, float
.output
.param SV_Position.xyzw, o0.xyzw, float, POS
.param SV_CullDistance.x, o1.x, float, CULLDST
.param SV_ClipDistance.y, o1.y, float, CLIPDST
.descriptors
.text
label l1
...
mov o1.x <v4:f32>, sr1 <s:f32>
mov o2.x <v4:f32>, sr2 <s:f32> // Note the .x write mask!
ret
whereas, when compiling using FXC and parsing the TPF using
vkd3d-compiler we get:
vs_4_0
.input
.param POSITION.xyzw, v0.xyzw, float
.output
.param SV_POSITION.xyzw, o0.xyzw, float, POS
.param SV_CULLDISTANCE.x, o1.x, float, CULLDST
.param SV_CLIPDISTANCE.y, o1.y, float, CLIPDST
.descriptors
.text
label l1
mov o0.xyzw <v4:f32>, v0.xyzw <v4:f32>
mov o1.x <v4:f32>, v0.x <v4:f32>
mov o2.y <v4:f32>, v0.y <v4:f32> // Note the .y write mask.
ret
This only really matters for cases where we have a system value semantic
whose mask doesn't start at .x, which is very rare. For instance, it
requires the clip/cull distance combo, which share registers, so one of
them pushes the other to start on another component.
According to the tests, the only thing relying on this behaviour is the
handling of private variables for system value semantics on the SPIR-V
backend, which expects destination write masks as if the element started
at .x even though it might not. This is modified then.
Here I am just printing a trace message on the rare situation where
GL_MAX_CLIP_DISTANCES is less than we need.
The maximum in Direct3D is given by D3D#_CLIP_OR_CULL_DISTANCE_COUNT which
is 8, which seems expectable here.
Alternatively we could add a clip-distance capability and only enable
it if gl_maxClipDistances is >= 8.
Another potential problem is that OpenGL expects the gl_ClipDistance[]
array to be the same size on every shader it is declared, which is a
restriction I am not sure Direct3D has with its SV_ClipDistance
components.
Co-authored-by: Anna (navi) Figueiredo Gomes <agomes@codeweavers.com>
WARP seems to be completely off for large argument values. The
difference quickly becomes of order of magnitudes, not ULPs. So
we ensure we test hyperbolic functions mostly for small arguments,
and skip WARP for large arguments.
We used to need workarounds when we used scanf() to parse float
numbers, but now we use strtof() which supports "inf" properly.
On the other hand, on some platforms it is the workaround that
now fails with a range error.
We used to need workarounds when we used scanf() to parse float
numbers, but now we use strtof() which supports "inf" properly.
On the other hand, on some platforms it is the workaround that
now fails with a range error.
This directive requires specific shader models to be tested for
compilation, bypassing the default behaviour where only one version from
each shader model set (SM1-3, SM4-5, SM6) is compiled.
