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>
When calling vrend_renderer_transfer_write_iov through
vrend_renderer_transfer_iov, we sometimes come down these
code-paths with the context 0 active, but the non-zero context being
passed as the context-pointer. Trying to do any caching based on this
will only lead to incorrect behavior.
There's little point in trying to fixup the caching in the ctx0 for
this call-site, as there's no other code-path using ctx0 that tries
to play ball with the cache.
So let's get rid ot the context-argument when possible, and pass a
NULL-pointer when it can come either from ctx0 or a rendering-context.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Without this, the next patch gets trickier, because we try to
*avoid* passing down the wrong data rather than trying to react to it.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This argument is unused, and the function is not a part of the external
API, so there's little point in passing it just to discard it again.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Context name length was being ignored and strncpy does not enforce
null termination but the destination was being used as a null terminated
string.
Change-Id: I715394b364130578a1a6a319dc16927261523d71
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
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>
GL_TEXTURE_LOD_BIAS is supported in GLES at least since 3.0,
This also fixes a number of piglits when run on a GLES host.
GL_TEXTURE_SEAMLESS_CUBE_MAP is not supported on the other hand.
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 GLES extension has been merged into the OpenGL registry, so it may
now become available.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
To avoid that the guest sends mixed color attachments when this is not
supported test this and add an according caps flag.
Related: #88 (a full fix needs a mesa side patch to make use of the
flag sent)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This test also tends to time out sometimes
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reduce the number of test processes run by the CI to 1/8 of the number of
available processors.
Normally only run the build and sanity checks, and only run the test suites
for merge requests.
Also fix some string marker that seems to make problems.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This tracks more accurately what exactly needs to be updated.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
We're going to have to do this anyway, so let's just do it cleanly
right away.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
These settings can't change in the lifetime of the texture-view,
so let's set them up front instead of re-setting them on every re-emit.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
There's no point in changing the texture-binding unless we're going to
do something with the texture-stage.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Gert Wollny
Erik Faye-Lund
David Riley