Closes: #74
v2: * Enable enhanced layouts in the guest only when the host supports
it, because with indirect arrays enabled we re-emit the layout
the guest send.
* enable indirect arrays independently from the host capabilities
(following Eriks comments)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
On GLES Mesa rejects arrays of arrays as TCS and TES shader inputs and outputs.
This is based on section 4.3 of the GLSL 3.20 ES standard where an error should be
produced for "Per-vertex-arrayed arrays of arrays" and "For non-per-vertex-arrayed
array of arrays", so apparently something like
in vec4 [][N];
is not allowed and on GLES interface blocks have to be used instead. In addition the
code needed some fixups when interface blocks are used.
v2: Emit correct type for elements in blocks
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
This is not legal. This fix help with "The Talos Principle" that triggers
emitting an invariant shader.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This fixes most of the piglit:
arb_shader_image_load_store-qualifiers
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
With GLSL ES a format layout is requires, and with GL it doesn't hurt to
add it, so always emit rgba32f when no format is given.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On GL WR translates to writable, but on GLES we translate this
to writeonly because for most formats one has to specify one or
the other, so if we have an image with the TGSI WR specification,
and read from it, we drop the Writable flag. For the images that
allow RW this is of no consequence, and for the others a write
access will fail instead of the read access, but this doesn't
constitue a regression because we couldn't do both - read and
write - anyway.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Softpipe doesn't support ARB_GLES3_1_compatibility but can support
NV_shader_atomic_float and this is needed for some dEQP-GLES31 tests to be
run on a softpipe GL host.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
(u|i)mulExtended are provided by ARB_gpu_shaders5 but also by
MESA_shader_integer_functions and only the latter is supported by softpipe
so fall back to this extension if needed.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This is not required and actually an error.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
Fixes 1D part of piglits of: bin/arb_shader_image_size-builtin
(The tests require glViewportIndexedfv enabled with !182)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Fixes: KHR-GL33.texture_size_promotion.functional
v2: Put bias at right position when offset is present
Fixes piglit: texelFetch offset 140 fs isampler2DRect
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Fixes piglits on GLES host:
tex-miplevel-selection * 1D*
The only piglits that are not fixed from the tex-miplevel-selection
are those including sampler1DArrayShadow. emulating these by using
sampler2DArrayShadow is not always possible, because GLSL doesn't
provide the required overloads.
Namely textureOffset, textureLod, textureLodOffset, and texture with
bias parameter are not available.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
samplers on GLES
Since the sampler is emulated by a 2D sampler the offset must also be a
2D vector and the coordinate argument must be ivec2.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Since the 1D texture arrays are emulated by using 2D texture
arrays the number of array layers is in the z component.
Fixes piglits on GLES:
textureSize * *sampler1DArray
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
These textures are emulated by 2D textures and textureSize needs the swizzle
for the result to be assignable to a float value.
Fixes piglits on GLES hosts:
textureSize * *sampler1D
textureSize * *sampler1DShadow
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This enables indexed access to viewports on GLES hosts.
v2: Also add the extension to shaders when needed
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes a number of piglitson GLES hosts. e.g. :
texelFetch * sampler2DMS * *
v2: Manually shift pixel center only on GLES
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
A recent change in the mesa glsl code mesa/e551040c resulted in a
regression for
dEQP-GLES31.functional.shaders.builtin_functions.
integer.umulextended.uvec*
because the generated TGSI was staring to use only certain components of
the temporary return values. Therefore, it became visible that the
swizzle was not honored on these values.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Dave Airlie airlied@redhat.com>
With enhanced layouts and input arrays enabled it may happen that more then
one shader IO variable have the same sid, and since the other parts of the
glsl_name are not available at this point rewrite the patching routine to
be able to patch more than one instance of a delaration with the same
variable prefix.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
By enabling input arrays the TGSI may emit code that defines a number
of POS inputs individually, but accesses them indirectly. Rewriting them
as array makes it possible to emit proper GLSL in this case.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Some varying outputs can be directly used for tranform feedback, so don't
emit an additional varying in these cases. This should save a move
instruction and also reduces the possibility of hitting the output varying
limit.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Same as for outputs, since inputs might be passed interleaved we also
have to check the access mask and if the component comes with an offset
then we have to shift the swizzle.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
If a variable has component offsets we have to correct the swizzles.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
The guest might send component layouts that we don't want to deal with
when we are in the no-guest-arrays code path, so rewrite the component
layouts and then rename the variables.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
If the guest sends individual arrays they might be numbered in an
abitrary way, but we need them ordered to be able to find corresponding
in and outputs.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
With input arrays enabled the guest might actually send arrays with the
same sid, and for TCS, GEOM, and TES shaders these might initially not
contain any information about the components, so we have to distinguish
these IO variables also based on the array ID.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
These swizzles were applied to the wrong argument. When we start to use
the component masks for inputs, this becomes relevant.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Arrays of arrays is only required when the host supports it (but it is preferred)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
mesa optimizes away the information about input layouts for generics and
patches for TCS, TES, and GEOM shaders (all that pass these inputs as
arrays), but when input arrays are allowed, then these varyings may
actually have overlapping layouts (at least some piglits do, even though
they don't specifically require ARB_enhanced_layouts).
To be able to link shaders like these with enables arrays pass this info
to the next stage.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
With individual arrays the guest may send layouts with
overlapping locations, so we need to keep track of the usage masks
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Extract the generation of the block and varable name and use these
functions.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Arrays of arrays are way easier to handle and they are available on GLES
3.1, D-GL 4.3, and all hardware that is supported by mesa. The old code
path is still able to use blocks for passing parameters to and from
tesselation and geometry stages, but for the new code path they are
required.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Since TGSI is vector based it passes clip and cull distances as
values or arrays of vec4 values, but the glsl shader wants to access it
as arrays of scalars. To work around this handle the FS input just like
the outputs, i.e. introduce an array of temporaries vec4 and copy the
data there.
For all other shader types the access to the values only needs to take
account of the possibility of indirect adressing or an array offset.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
v2: - Fix copy-paste error when evaluating patch output as source, i.e.
use the output patch when outputs are handled as source
- Fix some whitespace error
Closes: #77
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> (v1)
Declare the generated generic IO arrays just like it is done for the
individual ones as declared by the guest and use the same code path to
generate the dest and source info.
v2: Correct test when a generic output is used as input
Signed-off-by: Gert Wollny <gert.wollny@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> (v1)
When we enable indiviudal IO arrays that are passed from the host we
will no longer generate the one big array, but we know only after all
declarations have been parsed, whether the guest emitted these arrays or
whether we have indirect access to elements but no arrays so that we
need to build them. So do this array generation after parsing the
declarations.
v2: - If available use the output ranges size of the previous shader when
defining the input range for the generated arrays, mesa might have
optimized away some individual values.
- Add a GLSL version requirement when an interface block will be created.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> (v1)
Since GLES 3.1 supports IO arrays of arrays but D-GL only as of 4.3 and
D-GL supports interface blocks since 3.1 we prefer not emitting blocks
for GLES, with the exception of the TCS->TES out->in, where arrays of
arrays can't be used and for FS out where usually no array of array will
be created anyway.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Gert Wollny