Adds "In" postfix to the "gl_TessCoord" on entry point arguments decompilation stage if built in type is "BuiltInTessCoord" and execution mode is "ExecutionModeQuads". And declares shadow variable "gl_TessCoord" on entry point declarations.
We don't need to keep track of them because when the block.condition is
either a SPIRConstant or a SPIRVariable, we can get the type directly in
the get_case_list.
Signed-off-by: Sebastián Aedo <saedo@codeweavers.com>
Fragment shaders that require explicit early fragment tests are incompatible
with specifying depth and stencil values within the shader. If explicit early
fragment tests is specified, remove the depth and stencil outputs from the
output structure, and replace them with dummy local variables.
Add CompilerMSL:uses_explicit_early_fragment_test() function to consolidate
testing for whether early fragment tests are required.
Add two unit tests for depth-out with, and without, early fragment tests.
Now we added block.cases_32bit as requested and we only parse if the
remaining ops are a multiple of 2. None of them are mutable because we
return a reference of them depending of the op.condition width.
Signed-off-by: Sebastián Aedo <saedo@codeweavers.com>
We can safely cast the value since we check previously that we're not
using a uint64_t as the selector.
Signed-off-by: Sebastián Aedo <saedo@codeweavers.com>
SPIR-V allows an image to be marked as a depth image, but with a non-depth
format. Such images should be read or sampled as vectors instead of scalars,
except when they are subject to compare operations.
Don't mark an OpSampledImage as using a compare operation just because the
image contains a depth marker. Instead, require that a compare operation
is actually used on that image.
Compiler::image_is_comparison() was really testing whether an image is a
depth image, since it incorporates the depth marker. Rename that function
to is_depth_image(), to clarify what it is really testing.
In Compiler::is_depth_image(), do not treat an image as a depth image
if it has been explicitly marked with a color format, unless the image
is subject to compare operations.
In CompilerMSL::to_function_name(), test for compare operations
specifically, rather than assuming them from the depth-image marker.
CompilerGLSL and CompilerMSL still contain a number of internal tests that
use is_depth_image() both for testing for a depth image, and for testing
whether compare operations are being used. I've left these as they are
for now, but these should be cleaned up at some point.
Add unit tests for fetch/sample depth images with color formats and no compare ops.
This is somewhat awkward to support, but the best effort we can do here
is to analyze various Load/Store opcodes and deduce the ideal overall
alignment based on this. This is not a 100% perfect solution, but should
be correct for any reasonable use case.
Also fix various nitpicks with BDA support while I'm at it.
Apparently, it's legal to use a selection construct where both paths
branch to same location, but a different merge point is used.
This breaks many assumptions the variable scope analyzer makes.
The only logical way to generate code for this scenario is to treat the
selection construct as a trivial switch construct with only a default
case.
We don't need to keep track of the type itself, only its width since the
type check of the OpSwitch can be done at runtime. This also avoids
creating a dangling reference.
Signed-off-by: Sebastián Aedo <saedo@codeweavers.com>
Only emit user(locnN) for tess builtin input variables, and allow output builtin
to emit user(clip/cullN). Previously, output builtin would emit location if
input builtin also existed.
Moving out the logic from the parser as requested because it's sensitive
to try to keep the parsing the most simple process as said.
For that, the load_types is now tracked in the ParsedIR, which can be
accessed in the Compiler struct. The switch cases are fixed in the CFG
stage since that's the point where the nullptr is deref.
Signed-off-by: Sebastián Aedo <saedo@codeweavers.com>
According to the spec, if the `condition` has a type wider than 32 bits,
the literals to be compared with will be of that size as well.
This caused some misalignments if the `condition` was bigger than 32,
causing a nullptr return without further explanation.
Currently neither GLSL nor MSL supports uint64 as the condition but the
SPIRV allows it anyway.
This also fixes#1768.
Signed-off-by: Sebastián Aedo <saedo@codeweavers.com>
Previous test for SPIRVCrossDecorationPhysicalTypePacked on parent struct
when unpacking member struct was too restrictive, and not needed as long
as padding compensates.
Populate member_type_index_redirection as reverse lookup, not forward lookup.
Move use of member_type_index_redirection from CompilerMSL::to_member_reference()
to CompilerGLSL::access_chain_internal() to access all redirected type info,
not just name.
Promote to short instead and do simple casts on load/store instead.
Not 100% complete fix since structs can contain booleans, but this is
getting into pretty ridiculously complicated territory.
Additional usecases include array and vector indexing, variable declarations,
loop initializers, function return values, switch statement evaluations,
and various specialized MSL operations.
Ultimately, we might consider refactoring CompilerMSL::to_expression()
to always take into consideration possible unpacking behavior.
Refactor CompilerGLSL::to_enclosed_unpacked_expression()
for conciseness and consistency with similar functionality.
