DXIL handles are used to represent descriptors. Currently they are
translated to registers of the appropriate type (depending on the
descriptor type) and three indices. The first two indices are used
to represent the descriptor itself (through its signature and array
index), and are filled when the handle itself is created. The last
index is used with constant buffers to address the data inside the
buffer itself, and it goes unused with other descriptor types.
As currently implemented, however, registers for descriptors other
than constant buffers are still created with three indices, even if
the last one is useless and set to -1. In the interest of creating
more sensible VSIR code, this is now removed: DXIL handles are
created with just two indices; a third one is added when accessing
constant buffers, and nothing is changed for other descriptor types.
We need users of a value to be freed before the value itself is.
Due to copy propagation or use of the pre-allocated error instruction,
static_initializers can contain values that will be used in function blocks.
Historically the SPIR-V backend was only fed by the TPF parser,
which only generates _sat destination modifiers. Now it is fed
by the D3DBC parser too (among others), so it mustn't assert on
other modifiers.
Modifier _pp can be trivially ignored. Modifier _centroid would
probably require some handling, but I'm not immediately sure of
what should happen and it doesn't look like a very urgent thing
anyway, so I'm degrading the assertion to FIXME().
Object data is used for strings, textures, and shaders. Samplers are handled separately.
The section is a contigious stream of <id><size><object-data>, size field is used
to advance to the next <id> position.
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
The primary goal here is to move compilation profile type and version
check outside of a parsing stage. Default values for parameters were
never subjected to this fixup, and it does look tpf-specific, so moving
it where it belongs.
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Our ASM dumper currently hides or interprets some register indices
in order to match users expectations. This can be inconvenient for
developers, though, because it makes it harder to understand what's
really going on in the VSIR code when reading logs. With this change
the whole index structure is dumped.
SPIR-V images have a "depth" parameter that, as far as I understand
(the spec doesn't look terribly clear in that regard), specifies
whether the image can be used for depth-comparison operations.
In TPF (and therefore in VSIR) the same information is specified
on the sampler type instead of on the image type. This puts us in
a hard spot, because in principle an image can be used with
many different samplers, and the mapping might even be unknown
at compilation time, so it's not clear how we should define our
images.
We currently have some algorithms to deal with that, but they are
incomplete and lead to SPIR-V validation errors like:
Expected Image to have the same type as Result Type Image
%63 = OpSampledImage %62 %59 %61
The problem here is that the image has a non-depth type, but is
being sampled as a depth image. This check was added recently to
SPIRV-Tools, so we became aware of the problem.
As I said, it's not easy in general to decide whether an image is
going to be sampled with depth-comparison operators or not.
Fortunately the SPIR-V spec allow to mark the depth parameter as
unknown (using value 2), so until we come up with something better
we use that for all images to please the validator and avoid
giving misleading hints to the driver.
Numeric types are used very frequently, and doing a tree search
each time one is needed tends to waste a lot of time.
I ran the compilation of ~1000 DXBC-TPF shaders randomly taken from
my collection and measured the performance using callgrind and the
kcachegrind "cycle count" estimation.
BEFORE:
* 1,764,035,136 cycles
* 1,767,948,767 cycles
* 1,773,927,734 cycles
AFTER:
* 1,472,384,755 cycles
* 1,469,506,188 cycles
* 1,470,191,425 cycles
So callgrind would estimate a 16% improvement at least.
Enables the bounded range to be mapped to the unbounded one, instead of
being mapped to a separate binding which will be populated from the same
d3d12 descriptors as the unbounded one.
