If an ir_dereference_array has non-constant components, there's no
point in trying to evaluate its value (which involves walking down
the tree and possibly allocating memory for portions of the subtree
which are constant).
This also removes convoluted tree walking in opt_constant_folding(),
which tries to fold constants while walking up the tree. No need to
walk down, then up, then down again.
We did this for swizzles and expressions already, but I was lazy
back in the day and didn't do this for ir_dereference_array.
No change in shader-db.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We could probably clean this up more (maybe make it a method), but at
least there's only one copy of this code now, and that's a start.
No change in shader-db.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It looks like this was missed when converting opt_constant_folding()
from a hierarchical visitor to an rvalue visitor in 6606fde3.
ir_rvalue_visitor already processes values on the way back up the tree,
so we will have already visited every child node. There's no point in
doing it again.
No change in shader-db.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The pass ultimately skips over any entries with assignment_count != 1,
so there's no need to do further work once we've determined that there
are multiple assignments.
The constant value could be a large array (i.e. uvec4[327]), at which
point skipping the constant_expression_value() call (and the clone()
call within) can save us piles of memory.
No change in shader-db.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
I've added this to nir_gather_info(), but also to glsl_to_nir() as a
temporary measure, since the i965 GL driver today doesn't use
nir_gather_info() yet.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I don't know what the intention was here, but this function returns
void. We can't assert anything about its return value.
Fixes "make check" failures.
v2: Also fix prototype for the function (caught by Jordan).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Drop extra #include which is otherwise unneeded (and makes this header
difficult to include from outside of src/mesa).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
With algebraic-opt support for lowering div to shift, the driver would
like to be able to run this pass *after* the main opt-loop, and then
conditionally re-run the opt-loop if this pass actually lowered some-
thing.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Not sure how we didn't hit this already, but since we want fdiv
converted into mul + rcp, we should set this.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
In the glsl->tgsi path, this already gets translated to VAR8, which
matches up with rasterizer->sprite_coord_enable.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
When we got NIR directly from state tracker (vs using tgsi_to_nir) we
need to realize this and skip some TGSI specific hacks.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
INTERP is defined (by me) to have to have a INPUT source. However the
state tracker does not always obey this. This happens due to varying
packing logic introducing additional mov's which can't always be undone.
Instead of just giving up, we instead try harder to find the original
input. This won't always be possible, for example with indirect
accesses. There's not much we can (easily) do about that though.
This fixes the remaining interpolateAt* failures in dEQP:
dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at*
some of which were asserting due to INTERP_* being passed a non-input.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This fixes
dEQP-GLES31.functional.draw_indirect.draw_elements_indirect.*.default_attribute
These tests were causing a const vbo to be set up, and were small enough
draws that the logic was trying to go via the push path (which emits
data directly into the cmd stream rather than uploading a user vbo).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This was handled in handleTEX(), however the way the logic works, those
extra arguments aren't added on by then, so it did nothing. Instead we
must duplicate that bit here. GK110 appears to complain about
MISALIGNED_GPR, however it's reasonable to believe that GK104 has the
same requirements.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95403
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cull distances are just a special case of clip distances as far as the
hardware is concerned. Make sure that the relevant "planes" are enabled,
and flip the clip mode to cull for those.
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
[imirkin: add enables on nvc0, add nv50 support]
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
The pass that st/mesa relies on to combine clip and cull distances has
been reverted, so we can't expose ARB_cull_distance until that is
resolved.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We used to use a meta path on gen8 but we haven't since c7cf17ae75. We
might as well delete the meta path since blorp works on all gens.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We used to use a meta path because blorp didn't support 16x MSAA. Now it
does, so we don't need the meta paths anymore.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We used to use a meta path because blorp didn't support 16x MSAA. Now it
does, so we don't need the meta paths anymore.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The helper was initially created to allow us to set reasonable defaults as
we mutated the brw_blorp_prog_data structure in preparation for NIR. Now
that everything is going through brw_blorp_compile_nir_shader() which fully
fills out the brw_blorp_prog_data structure, we don't need the helper.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
NIR gets kind of awkward when you have a 3-component vector with two floats
and one int. This led to us accidentally going through float for the
sample index. It doesn't hurt anything but it also isn't needed.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The original code-flow tried to map original blorp. This puts things more
where they belong and simplifies some of the logic.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
There's no reason to be passing a whole struct around just for a single
boolean. We can create it later when we actually need to use it as a key.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This array allows the push constants to be re-arranged on upload. The
actual arrangement will, eventually, come from the back-end compiler.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Intel hardware does a form of multisample compression that involves an
auxilary surface called the MCS. When an MCS is in use, you have to first
sample from the MCS with a special opcode and then pass the result of that
operation into the next sample instrucion. Normally, we just do this
ourselves in the back-end, but we want to expose that functionality to NIR
so that we can use MCS values directly in NIR-based blorp.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is similar to nir_channel except that it lets you grab more than one
channel by providing a mask.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's no reason for having a macro *and* a python generator. We can
easily just do the whole thing in python. This has the advantage that we
are no longer definining ALU# macros which conflict with the ones in
brw_fs_builder.h.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
