This is required when an out argument involves an array index that is either
a global variable modified by the function or another out argument in the
same function call.
Fixes the shaders/out-parameter-indexing/vs-inout-index-inout-* tests.
v2:
- modify the ir_dereference_array nodes in place
- use ir_hierarchical_visitor
v3: use base_ir (Ian Romanick)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
No change in behavior. ralloc_size is equivalent to rzalloc_size.
That will change though.
Calls not switched to rzalloc_size:
- ralloc_vasprintf
- glsl_type::name allocation (it's filled with snprintf)
- C++ classes where valgrind didn't show uninitialized values
I switched most of non-glsl stuff to rzalloc without checking whether
it's really needed.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
this fixes some of the regressions with
"ralloc: remove memset from ralloc_size"
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Switch to use memory allocations which zero memory for places
where needed.
v2: modify and rebase on top of Marek's series (Tapani)
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
When blending with GL_COLORBURN_KHR and these colors:
dst = <0.372549027, 0.372549027, 0.372549027, 0.372549027>
src = <0.09375, 0.046875, 0.0, 0.375>
the normalized dst value became 0.99999994 (due to precision problems
in the floating point divide of rgb by alpha). This caused the color
burn equation to fail the dst >= 1.0 comparison. The blue channel would
then fall through to the dst < 1.0 && src >= 0 comparison, which was
true, since src.b == 0. This produced a factor of 0.0 instead of 1.0.
This is an inherent numerical instability in the color burn and dodge
equations - depending on the precision of alpha scaling, the value can
be either 0.0 or 1.0. Technically, GLSL floating point division doesn't
even guarantee that 0.372549027 / 0.372549027 = 1.0. So arguably, the
CTS should allow either value. I've filed a bug at Khronos for further
discussion (linked below).
In the meantime, this patch improves the precision of alpha scaling by
replacing the division with (rgb == alpha ? 1.0 : rgb / alpha). We may
not need this long term, but for now, it fixes the following CTS tests:
ES31-CTS.blend_equation_advanced.blend_specific.GL_COLORBURN_KHR
ES31-CTS.blend_equation_advanced.blend_all.GL_COLORBURN_KHR_all_qualifier
Cc: currojerez@riseup.net
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16042
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
When checking if a type contains doubles, integers, samples, etc. we
check if the current type is a record or array, but not if it is an
interface.
This commit also inspects if the type is an interface.
It fixes spec/arb_enhanced_layouts/compiler/transform-feedback-layout-qualifiers/xfb_offset/invalid-block-with-double.vert
piglit test.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
SSO validation and other program interface queries want to see that
unsized (non-patch) TCS output/TES input arrays are implicitly sized
to gl_MaxPatchVertices.
By the time we create the program resource lists, we've sized the arrays
to their actual size. (We try to create TCS output arrays to match the
output patch size right away, and at this point, we should have shrunk
TES input arrays.) One option would be to keep them sized to
gl_MaxPatchVertices, and defer shrinking them. But that's a big change,
and I don't think it's a good idea.
Instead, this patch introduces a new ir_variable flag which indicates
the variable is implicitly to gl_MaxPatchVertices. Then, the linker
munges the types when creating the resource list, ignoring the size
in the IR's types. Basically, lie about it for resource queries.
It's ugly, but I think it ought to work.
We probably could use var->data.implicit_sized_array for this, but
I opted for a separate bit to try and avoid convoluting the existing
SSBO handling. They're similar in concept, but share none of the
same code...
Fixes:
ES31-CTS.core.tessellation_shader.single.xfb_captures_data_from_correct_stage
and the ES32-CTS and ESEXT-CTS variants.
v2: Add a comment (requested by Timothy, written by me).
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
The next commit will use this in add_shader_variable - this just
separates out some of the mechanical changes for easier review.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Fixes the following compile error, present when the SHA1 library is libgcrypt:
CCLD glsl/tests/cache-test
glsl/.libs/libglsl.a(libmesautil_la-mesa-sha1.o): In function `call_once':
/mesa/src/util/../../include/c11/threads_posix.h:96: undefined reference to `pthread_once'
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
PYTHON_GEN is defined to the exact same thing in both
Makefile.glsl.am and Makefile.nir.am. This makes automake complain,
so let's lift the definition up to Makefile.am, the same way as
MKDIR_GEN.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Tested-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Otherwise it'll be missing from the tarball.
Fixes: 094fe3a959 ("nir: move nir_shader_info to a common compiler header")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Default precision qualifier for a data type could be set several times
inside a shader. This patch allows to update the default precision
qualifier for the given type that is saved in the symbol table.
If it is not in the symbol table, just add it.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97804
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
As of 59864e8e02 we just use the location assigned by the front-end and
no longer need this for i965.
Since there were some issues in the logic with assigning arrays the same
driver location if they didn't start at the same location just remove it
and let other drivers implement a solution if needed when they add
ARB_enhanced_layouts support.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This temporary helper is no longer needed now that we have finished
refactoring common shader metadata.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And set system values read directly in shader_info.
st/mesa changes where:
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And set outputs written directly in shader_info.
st/mesa changes where:
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And set set inputs_read directly in shader_info.
To avoid regressions between changes this change is a squashed
version of the following patches.
st/mesa changes where:
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Here we move OriginUpperLeft and PixelCenterInteger into gl_program
all other fields have been replace by shader_info.
V2: Don't use anonymous union/structs to hold vertex/fragment fields
suggested by Ian.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Note we access shader_info from the program struct rather than the
nir_shader pointer because shader cache won't create a nir_shader.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This function is added here to ease refactoring towards using the new shared
shader_info. Once refactoring is complete and values are set directly it
will be removed.
We call it from _mesa_copy_linked_program_data() rather than glsl_to_nir()
so that the values will be set for all drivers. In order to do this some
calls need to be moved around so that we make sure to call
do_set_program_inouts() before _mesa_copy_linked_program_data()
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
And use this field as the source for shader info in the nir_shader
this will allow us to set some of these fields from GLSL directly.
It will also simplify restoring from shader cache and allow the
removal of duplicate fields from GLSL.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
When restoring something from shader cache we won't have and don't
want to create a nir_shader this change detaches the two.
There are other advantages such as being able to reuse the
shader info populated by GLSL IR.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This will allow use to stop copying values between structs and
will also simplify handling handling these values in the shader cache.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
