The same code appeared in both branches; pull it above the if statement.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The caller already computes it. Now that we have stage specific
functions, it's really easy to pass this in.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The caller already computes it. Now that we have stage specific
functions, it's really easy to pass this in.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Now that each stage is directly calling brw_nir_lower_io(), and we have
per-stage helper functions, it makes sense to just call the relevant one
directly, rather than going through multiple switch statements.
This also eliminates stupid function parameters, such as the two that
only apply to vertex attributes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
These functions are both giant switch statements where most cases don't
overlap at all. Let's put the bulk of the work in per-stage helpers.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Most cases already call nir_lower_io explicitly for input and output
lowering. This catch all isn't very useful anymore - we can just add it
to the remaining cases.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This simplifies things. Every caller of brw_nir_lower_io() immediately
calls brw_postprocess_nir(). The only real change this will have is
that we get an extra brw_nir_optimize() call when compiling compute
shaders, but that seems fine.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
We've now hit literally every case other than geometry shaders (and
compute shaders, but those are a no-op). So, let's just move geometry
shaders over too and be done with it.
The only advantage to doing this at link time was to save the expense
of running the pass on recompiles. But we're already running a lot of
passes, and the extra code complexity isn't worth it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Shorter than compiler->scalar_stage[MESA_SHADER_GEOMETRY], which can
help with line-wrapping.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The Vulkan driver wants to be able to delete fragment outputs that are
beyond key.nr_color_regions; this is a lot easier if we lower outputs at
specialization time rather than link time.
(Rationale added to commit message by Ken)
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Without this, on SIMD 16 the send instruction destination will appear
to write more than one destination register, causing the simulator to
report an error.
Of course, the send instruction can actually write more than one
destination register regardless of the type set for the destination,
so this is a bit strange.
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reduce the amount of duplicated code by re-using
nvc0_program_validate(). While we are at it, change the prototype
to return void and remove nvc0_compute.h which is now useless.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Pierre Moreau <pierre.morrow@free.fr>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
No reason to not validate those global buffers and this might avoid
fails if someone try to use the global memory from compute programs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Pierre Moreau <pierre.morrow@free.fr>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
While we are at it, rename it to nvc0_compute_validate_globals() and
update its prototype.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Pierre Moreau <pierre.morrow@free.fr>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Since commit d1314de293 we ignore
damage passed to SwapBuffersWithDamage.
Wayland 1.10 now has functionality that allows us to properly
process those damage rectangles, and a way to query if it's
available.
Now we can use wl_surface.damage_buffer and interpret the incoming
damage as being in buffer co-ordinates.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Will allow us to catch/prevent issues, like the one in mesa 11.2.0-rc1.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Without this mesa 11.2.0-rc1 ended up busted :-(
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Repored-by: Ondřej Súkup <mimi.vx@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Allows us to transform
add res src0 src1
mov.sat dst -res
into
add.sat dst -src0 -src1
No shader-db changes.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Allows us to transform
mul res src0 src1
mov.sat dst -res
into
mul.sat dst src0 -src1
instructions in affected programs: 45246 -> 45054 (-0.42%)
helped: 162
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It's not correct to CSE these multiplies
mul.sat dst1, -a, b
mul.sat dst2, a, b
by emitting a negated MOV from dst1 to dst2:
mul.sat dst1, -a, b
mov dst2, -dst1
Take 2.0*2.0 for example. The first multiply would produce 0.0 and the
second would produce 1.0.
Fixes bad generated code in 18 to 22 shaders:
instructions in affected programs: 432 -> 464 (7.41%)
helped: 4
HURT: 18
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Unclear to me whether it actually is a horizontal operation that cannot
be vectorized, but the fact that i965 generates the same code in either
case makes me less interested in finding out.
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94199
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Because I changed the swizzle check, I also need to adapt the return
values for each check.
It's basically almost the same as before, we just cross between STD and
STD_REV, and cross between ALT and ALT_REV
This fixes the rgba test in gl-1.0-readpixsanity (piglit) and also
fixes tri-flat (mesa demos).
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Previously loops like
do {
// ...
} while (false);
that did not have any other loop-branch instructions would not be
unrolled. This is commonly used to wrap multiline preprocessor macros.
This produces IR like
(loop (
...
break
))
Since limiting_terminator was NULL, the loop unroller would
throw up its hands and say, "I don't know how many iterations. How
can I unroll this?"
We can detect this another way. If there is no limiting_terminator
and the only loop-branch is a break as the last IR, there's only one
iteration.
On my very old checkout of shader-db, this removes a loop from Orbital
Explorer, but it does not otherwise affect the shader. The loop removed
is the one the compiler inserts surrounding the switch statement.
This change does prevent some seriously bad code generation in some
patches to meta shaders that I recently sent out for review.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
RGBA8 and BGRA8 unorm formats are compatible with the various
mem_copy functions. Their sRGB counterparts are also compatible
because they're also color-renderable (of importance when the
specified resource is a readbuffer) and they share the same
physical layout.
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Previously we allocated 4kB of push constant space for VS, GS, and PS
(for a total of 12kB) no matter what. This works, but doesn't fully
utilize the space - we have 16kB or 32kB of space.
This makes anv use the same method as brw - divide up the space evenly
among all active shader stages. This means HS and DS would get space,
if those shader stages existed.
In the future, we can probably do better by inspecting how many push
constants each shader stage uses, and weight things accordingly. But
this is strictly better than the old code, and ideally we'd justify
a fancier solution with actual performance data.
Rather than keeping separate {vs,hs,ds,gs}_start fields, we now store an
array indexed by the shader stage (MESA_SHADER_*). The 3DSTATE_URB_*
commands are also sequentially numbered. This makes it easy to just
emit them in a loop.
This simplifies the code a little, and also will make it easier to add
more credible HS and DS code later.
Not called from any other file. Remove _mesa_ prefix and update comments.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
To match the convention of other device driver functions.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The change "mesa/readpix: Don't clip in _mesa_readpixels()" caused a
few piglit regressions. The failing tests use glReadPixels to read
from the front color buffer. The problem is we were trying to read
from a non-existant front color buffer. The front color buffer is
created on demand in st/mesa. Since the missing buffer bounds were
effectively 0 x 0 the glReadPixels was totally clipped and returned
early.
The fix involves creating the real front color buffer when we're about
to try reading from it.
Tested with llvmpipe and VMware driver on Linux, Windows.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94253
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94254
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94257
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Unfortunately, glslang gives us cull/clip distance and GS streams even if
the shader doesn't use it whenever a shader is declared as version 450.
This is a glslang bug, but we can easily enough ignore it for now.
The descriptor sizes array gives the total number of each type of
descriptor that will ever be allocated from the pool, not the total amount
that may be in any particular set. In our case, this simply means that we
have to sum a bunch of things up and there we go.
