Commit 4717775abb removed the code turning
the corresponding DCL_INPUT instructions into NOPs, presumably because
vsir_program_remove_io_decls() now already removes them. That function
only removes the instructions though, not the declarations as such; we
now need to remove these from the "io_dcls" bitmap instead.
Commit 949708450b introduced support for
effect binaries embedded in DXBC containers, but only when using
auto-detection to determine the source type. That's undesirable;
although auto-detection is convenient for interactive use, it's not
necessarily suitable for use in e.g. scripts. It also meant this wasn't
listed through --print-source-types.
The semantic variables from a patch parameter are split as usual, with
the difference being that the semantic variable being added is a patch
variable itself, with the type being the split variable type, and its
number of control points being equal to the original patch variable's
number of control points. It is then stored in the original patch
variable as follows:
for (i = 0; i < n; ++i)
patch[i][f] := <inputpatch-sem-var>[i]
where n is the number of control points of "patch", and f is the field
index in patch corresponding to "<inputpatch-sem-var>".
We use special prefixes, "inputpatch-" or "outputpatch-", when adding
the semantic patch variables, in order to distinguish them from
non-patch semantic variables of the same name.
In anticipation of the need for is_patch_constant_func in
sm4_generate_vsir_reg_from_deref(), in order to generate vsir
registers from InputPatch/OutputPatch dereferences.
swprintf() expects the length of the buffer in WCHARs instead of bytes,
so ARRAY_SIZE() is used instead of sizeof().
This caused almost all tests to terminate abruptly with the following
message, in my machine:
*** buffer overflow detected ***: terminated
If the parameter is HLSL_STORAGE_IN, we add a cast from the arg to the
param type so that it can enter the function, however this cast should
not be considered part of the lhs on the implicit assignment that happens
if the var is also HLSL_STORAGE_OUT.
While so far it has been posible to do this at parse time, this must
happen after knowing if the complex cast is on the lhs or not.
The modified tests show that before this patch we are currently
miscompiling when this happens, because a complex lhs cast is transformed
into a load, and add_assigment() just stores to the generated "cast"
temp.
For example, given two arguments, half3 and float, and two functions,
func(float, float) and func(float3, float3), fxc/d3dcompiler prefers to
widen both arguments to float3.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
Pixel shader 1.x constants must be between -1 and 1, or they will be clamped,
even constants defined in the shader.
Also mark 1.x-specific features if any.
When the client acquires the Vulkan queue it has to ensure that
it is not submitting work before other work it depends on already
submitted through the Direct3D 12 API but currently in the internal
vkd3d queue. Currently we suggest to enqueue signalling a fence and
than wait for it before acquiring the Vulkan queue, which is
correct but excessive: it will wait not just for the work currently
in the queue to be submitted, but for it to be executed too,
introducing useless dependencies.
By adding a way to enqueue signalling a fence on the CPU side we
allow the client to wait for the currently outstanding work to
be submitted to Vulkan, but nothing more.
Commit 1ed8d907b3 inadvertently dropped
emitting the tessellator domain for domain shaders. Although Vulkan
environments allow us to write the tessellator domain from the hull
shader, the domain shader, or both, that's not generally true for OpenGL
environments.
We're explicitly replacing zero with one in the only place where the
plane count being zero or one makes a difference. It also make sense:
UNKNOWN is used for buffers, which for all intents and purposes have one
plane.
Vertex shaders do not have CMP, so we use SLT and MAD.
For example, this vertex shader:
uniform float4 f;
void main(inout float4 pos : position, out float4 t1 : TEXCOORD1)
{
t1 = (int4)f;
}
results in:
vs_2_0
dcl_position v0
slt r0, c0, -c0
frc r1, c0
add r2, -r1, c0
slt r1, -r1, r1
mad oT1, r0, r1, r2
mov oPos, v0
while we have the lower_cmp() pass, each time it is applied many
instructions are generated, so this patch introduces a specialized
version of the cast-to-int lowering for efficiency.
Turns out we are not doing this correctly in SM1, because the rounding
should be to the number that is closer to zero and lower_casts_to_int()
doesn't do that.
A vertex shader test is added since in SM1 they must rely on the SLT
operation instead of the CMP operation.
fxc compiles this method even without the backcompat option.
Furthermore, it even does it on ps_2_0 despite the fact that it maps to
a texldd instruction, which is not available on plain ps_2_0, nor ps_2_b,
only on ps_2_a and ps_3_0 according to documentation.
It is worth mentioning that the additional offset parameter is not
supported when lowering.
Otherwise ubsan reports these errors on the bitwise.shader_test:
libs/vkd3d-shader/hlsl_constant_ops.c:970:50: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
libs/vkd3d-shader/hlsl_constant_ops.c:970:50: runtime error: left shift of negative value -12
Otherwise ubsan reports errors such as:
libs/vkd3d-shader/spirv.c:7266:5: runtime error: null pointer passed as argument 1, which is declared to never be null
Otherwise ubsan reports runtime errors such as:
libs/vkd3d-shader/ir.c:4731:5: runtime error: null pointer passed as argument 1, which is declared to never be null
Otherwise when passing "-fsanitize=undefined" to the compiler, ubsan
reports such as:
libs/vkd3d-shader/ir.c:3794:5: runtime error: null pointer passed as argument 1, which is declared to never be null
Since we have -Wswitch, this forces the developer to update all relevant
switches when an enum case is added.
Places where the default is just a FIXME are left alone.
We apply distributivity to applicable expressions, specifically with
the following rewrite rules:
(x OPL a) OPR (x OPL b) -> x OPL (a OPR b)
(y OPR (x OPL a)) OPR (x OPL b) -> y OPR (x OPL (a OPR b))
((x OPL a) OPR y) OPR (x OPL b) -> (x OPL (a OPR b)) OPR y
(x OPL a) OPR ((x OPL b) OPR y) -> (x OPL (a OPR b)) OPR y
(x OPL a) OPR (y OPR (x OPL b)) -> (x OPL (a OPR b)) OPR y
where a, b are constants.
Like we did before commit 067e6deee4.
These skips aren't all that interesting; it's entirely intentional that
e.g. a 2.0-3.0 run wouldn't run 4.0 shaders.
The two branches do essentially the same thing, but in different
ways and each one omitting different details. In particular there
is no need to discriminate on whether the register is a relative
address, we can just copy the NULL pointer.
The hull shader control point normalisation pass already ensures
that output registers in the control point phase have two
indices (the control point index and the register index).
Consistent with how D3DXFindShaderComment() allows looking up comments
by tag. This also makes it a little easier to move CTAB generation out
of d3dbc.c.
It makes the code quite longer, but also easier to read and extend
with further properties.
A (desirable) side effect of this commit is that it is checked
whether I/O register types are legal depending on the shader type
and phase, while before that was assumed.
This commit introduces enum vsir_io_reg_type and enum vsir_phase
which shadow enum vkd3d_shader_register_type and enum
vkd3d_shader_opcode, with the goal of making the data tables
smaller.
Adjust the algorithm for deciding for which profiles to test compilation.
We first ensure that if the compilation result changes (most often as the result
of a feature introduced in a specific version), we test the versions immediately
on either side of the change, to validate that vkd3d-shader is emulating the
same version behaviour.
We then ensure that we are testing at least one version from each set of sm1,
sm4, and sm6.
Mainly in order to not waste time compile-testing the same version
more than once [as we do with e.g. the d3d11 and d3d12 runners, or
d3d12, GL, and Vulkan].
When a shader fails to compile for a range of versions, we want to validate that
we are correctly implementing that behaviour. E.g. if a feature requires shader
model 5.0, we should validate that it compiles correctly with 5.0 (which we do),
but also that it *fails* to compile with 4.1 (which we do not).
The obvious and simple solution is to simply run compile tests for each version.
There are, however, at least 12 versions of HLSL up to and including 6.0, at
least 10 of which are known to introduce new features. Shader compilation takes
about 10-15% of the time that draw and dispatch does, both for native and
(currently) vkd3d. Testing every version for every shader would add a
noticeable amount of time to the tests.
In practice, the interesting versions to test for most shaders are:
* At least one from each range 1-3, 4-5, and 6. It's common enough for the
semantics of the HLSL to differ between bytecode formats, or for features to
be added or removed across those boundaries.
* If the shader requires a given feature, we want to test both sides of the cusp
to ensure we're requiring the same version for the feature.
In practice this is 3 or 4 versions, which is measurably less than the 12 we'd
otherwise be running.
In order to achieve this goal of testing only the 3 or 4 interesting versions
for a shader, we need to know what version is actually required for a feature.
This is encoded in the shader itself using e.g. [pixel shader fail(sm<5)].
This patch therefore implements the first step towards this goal, namely,
determining which versions succeed and fail, so we can figure out which ones are
interesting.
We could require the test writer to specify which versions are interesting ahead
of time (e.g. "for version in 2.0 4.1 5.0 6.0") but this is both redundant (and
there are a *lot* of tests that need some feature gate) and easy for a test
writer to get wrong by missing interesting versions.
Sometimes SM1-3 shaders contain write masks that exceed the
signature element masks. That happens because SM1-3 shaders do not
have a concept of signature and signature masks, and OTOH aren't
always able to express any given write mask.
In VSIR we don't want to deal with I/O register masks exceeding the
corresponding signature element mask or usage mask, because, for
instance, for higher shader models it can complicate dealing with
DCL_INDEX_RANGE. In order to have uniform rules for all shader
models we normalise masks coming from SM1-3 shaders.
We don't do that normalisation when disassembling, in order to
preserve the expected output.
The previous names "not normalised" and "fully normalised" have meanings
which are likely to change with time. OTOH including a description of the
normalisation level in the enumerant seems excessive. Relating
normalisation levels to shader model versions might be a reasonable
compromise.
We normalize binary expressions by attempting to group constants
together, in order to facilitate further simplification of the
expressions.
For any binary operator OP, non-constants x, y, and constants a, b, we
apply the following rewrite rules:
a OP x -> x OP a, if OP is commutative.
(x OP a) OP b -> x OP (a OP b), if OP is associative.
(x OP a) OP y -> (x OP y) OP a, if OP is associative and commutative.
x OP (y OP a) -> (x OP y) OP a, if OP is associative.
Note that we consider floating point operations to be
non-associative.
The alternative to adding the vsir_program->tess_output_primitive and
vsir_program->tess_partitioning fields would be to emit the vsir
DCL_TESSELLATOR_OUTPUT_PRIMITIVE and DCL_TESSELLATOR_PARTITIONING
instructions, like DXIL does, but I think that the preference is to store
these kind of data directly in the vsir_program.
The combined sampler is created as a SAMPLER instead of a TEXTURE
because that fits all our current infrastructure. The only problem is
that in the CTAB it must appear as a Texture, so the new field
hlsl_type.is_combined_sampler is added.
Co-authored-by: Elizabeth Figura <zfigura@codeweavers.com>
Looking at the implementation of shader_sm4_read_dcl_sampler(), vsir
stores the resource index range both in
vkd3d_shader_instruction.declaration.sampler.range
and in the
vkd3d_shader_instruction.declaration.sampler.src.reg.idx[1-2]
indexes, so we do the same.
It is also worth noting that for shader models lower than 5.1, vsir
has a normalization on the ins->declaration src register indexes.
Refer to the following comment:
/* SM5.1 places a symbol identifier in idx[0] and moves
* other values up one slot. Normalize to SM5.1. */
on shader_sm4_read_param().
This normalization is also added to the generated vsir instructions.
Currently, when using Vulkan heaps, we create descriptor set
layouts with as many descriptors as allowed by the Vulkan
implementation limits. For some implementations this can mean
hundreds of millions of descriptors or more, which is wasteful,
given that even on the best resource binding tier Direct3D 12
applications should not expect to have more than a million usable
descriptors.
Recently this began being a problem, because since Mesa 24.2.7
the Intel driver advertises more than 200 million descriptors,
but pipeline compilation takes linear RAM in the number of
descriptors declared in the pipeline layout. This means that
compiling even a simple shader requires 10-20 GB of RAM.
In order to avoid using too much memory, with this commit we clamp
the number of descriptors declared in the set layouts to how many
we actually need to guarantee tier 3 resource binding support.
Creating a pool of 16k descriptors is wasteful if an allocator only uses
a fraction of them, so start at 1k and double for each subsequent
allocation until 16k is reached.
Now that our Vulkan descriptor sets contain only a single vkd3d
descriptor type, we're able to create descriptor pools containing only a
single vkd3d descriptor type as well. This avoids wasting unallocated
descriptors of one type when we run out of descriptors of another type.
We currently create statically sized descriptor pools, shared among
different descriptor types. Once we're unable to allocate a descriptor
set from a pool, we create a new pool. The unfortunate but predictable
consequence is that when we run out of descriptors of one type, we waste
any unallocated descriptors of the other types.
Dynamically adjusting the pool sizes could mitigate the issue, but it
seems non-trivial to handle all the edge cases, particularly in
situations where the descriptor count ratios change significantly
between frames. Instead, by storing only a single vkd3d descriptor type
in each Vulkan descriptor set we're able to create separate descriptor
pools for each vkd3d descriptor type, which also avoids the issue.
The main drawback of using separate descriptor sets for each descriptor
type is that we can no longer pack all bounded descriptor ranges into a
single descriptor set, potentially leaving fewer descriptor sets
available for unbounded ranges. That seems worth it, but we may end up
having to switch to a more complicated strategy if this ends up being a
problem on Vulkan implementations with a very limited number of
available descriptor sets.
Most I/O registers are already described by the shader signatures.
The registers that are not do not have any property other then
being used by the program or not, so they can be collectively
described with a bitmap.
The register storage class is now represented in
vkd3d_register_builtins, so the spirv_compiler_emit_io_register()
doesn't need to know it from the caller.
Instead of returning nonsense (such as, currently, a type with zero size).
In practice this improves error reporting for shaders such as the following:
void func(float x[])
{
float y[] = {x};
}
Currently this outputs a nonsense
test.hlsl:1:19: E5002: Implicit size arrays not allowed in function parameters.
test.hlsl:3:7: E5002: Implicit size arrays need to be initialized.
With this patch the second warning is removed.
Some test programs, particularly the shader runner, are built from
many different files nowadays, and a line number is relatively
cumbersome to use if you don't know which file that line comes from.
These are redundant either because we already have a broader tag like
"sm<6", or because the tests are never executed with the GLSL runner in
the first place.
Instead of using DCL_INPUT.
The main goal here is to eventually get rid of the I/O
declaration instructions. A positive side effect is that we don't
add a useless barrier to shaders which have a DCL_INPUT instruction
in the patch constant phase but don't actually read OUTCONTROLPOINT
registers.
This makes it available to all backends, without requiring an
ad-hoc solution for each of them. It also gets rid of an
undocumented flag we're currently passing to
DCL_CONTROL_POINT_PHASE.
Translate the instructions that contain hlsl_blocks. Also move
other control flow instructions such as HS_CONTROL_POINT_PHASE and
RET to the vsir_program so that we can directly iterate over it now.
These system values are bound to the same allocation rules as other
semantics: they can share registers with other semantics with the same
interpolation mode and they prefer forming shorter writemasks. However,
for some reason, these don't allow further semantics to share the same
register once allocated, except among themselves.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
