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>
Having this code overwrite whatever was done before is a gotcha waiting
to happen.
Signed-Off: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The range is needed to identify indirectly addresses IO values.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
EXT_texture_query_lod on GLES is proposed as extension providing for
GLES what ARB_texture_query_lod provides for D-GL.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On GLSL ES implicit conversion are not enabled by default. Since here the
evaluations are hard coded, just emit literal values according to the
types they are used with in the operations.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On GLES *Rect textures are not supported and emulated by using a normal
2D texture. Therefore, the texture coordinates must be normalized for
these cases and the LOD must be set to 0.
Fixes: piglits
textureGather with 2DRECT texture
arb_fragment_program_shadow/tex-shadow2drect
arb_fragment_program_shadow/txp-shadow2drect
glsl-fs-texture2drect -proj3 and -proj4
Related: #81 (some non-shader tests still fail for rect textures)
v2: - Reorder some conditions to make the control flow easier to follow
- correct WS (both Gurchetan)
Remark: For some of these piglits one must currently force GL 3.3 in the
guest, otherwise they fail because of GLSL version 1.50 not being
supported.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
GLES doesn't support 1D textures, so they are emulated by using 2D
textures and the access has to be fixed by adding the y lookup coordinate.
v2: simplify the code flow (Gurchetan)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
This function was added but never used. Let's get rid of it.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: 5d2dde4 ("strings: move to 3 strings, and patch extensions onto end of string 0 (v2)")
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This saves adding the padding and just appends the ext strings
v2: use emit_hdr for the precision strings (Gert)
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This uses the string array helpers to pass around the glsl strings
for the program.
This could be expanded on to provide more than 2 strings easily
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This will make things easier in a later patch.
Suggested by Gert.
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes the mem leak:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f49a7733c60 in realloc (/usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.0/libasan.so+0xdbc60)
#1 0x7f49a713100a in add_sampler_array ../../../../virgl-gitlab/src/vrend_shader.c:619
#2 0x7f49a71318cb in add_samplers ../../../../virgl-gitlab/src/vrend_shader.c:677
#3 0x7f49a713a780 in iter_declaration ../../../../virgl-gitlab/src/vrend_shader.c:1213
#4 0x7f49a7194c37 in tgsi_iterate_shader ../../../../../../virgl-gitlab/src/gallium/auxiliary/tgsi/tgsi_iterate.c:59
#5 0x7f49a7169a24 in vrend_convert_shader ../../../../virgl-gitlab/src/vrend_shader.c:5012
Closes: #85
[airlied: v2: free image arrays as well]
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This way all output originating from virglrenderer will be redirected.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: David Riley <davidriley@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is needed for guest GL >= 3.0 on GLES.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Gert Wollny
Erik Faye-Lund
Dave Airlie