These already have to be the same as VIRGL_TRANSFER_{TO,FROM}_HOST, as
defined by the protocol. There's no point in having a separate set of
internal names for them.
While we're at it, rewrite tan if as a switch for clarity. This allows
us to detect internal usage of invalid values.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
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>
Virglrenderer sometimes tries to remove resources from the hash table
twice. Which will mess up the ressource hash table and reference counts
and therefore and leads to qemu/virglrenderer crashes.
Reproducer:
(a) guest creates resource foo, id 42.
(b) guest creates an object bar referencing resource foo.
(c) guest unreferences resource foo.
-> resource id 42 is removed from hash.
(d) guest creates a new resource baz, re-using id 42.
(e) guest destroys object bar.
-> resource foo refcount goes down to zero.
-> resource id 42 gets removed from hash the second time,
but id 42 entry points to resource baz not foo now.
Oops.
Note that most linux kernel drivers will never ever re-use resource ids
due to a bug in the virtio-gpu kms driver, in which case this bug
doesn't cause any harm.
Root cause is that vrend_renderer_resource_destroy() may call
vrend_resource_remove(), depending on the call chain. This is wrong.
Only vrend_renderer_resource_unref() which is called when the guest
unreferences a resource should remove the id from the hash table by
calling vrend_resource_remove().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: <Gurchetan Singh gurchetansingh@chromium.org>
This is easier than having to remember environment variables.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
This means we can change them a bit more easily, for instance... from
command-line arguments!
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
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>
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>
Set the pre stage correctly when the TCS shader is missing on OpenGL and
warn about it when on OpenGL ES.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
We already have a helper for this, let's use it.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Erik Faye-Lund
Gert Wollny
Gerd Hoffmann
Stéphane Marchesin
Elie Tournier