GRAS_SU_DEPTH_PLANE_CNTL doesn't in fact seem to be anything to do with
alpha test. This fixes xonotic and (other than some iommu faults) gets
gnome-shell working.
Signed-off-by: Rob Clark <robdclark@gmail.com>
We don't need varying interpolators enabled for pos/psize out of the VS
(despite the fact that they show up in VS_OUT map), so emit these before
we append pos/psize to the linkage.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This was a hack which worked around the VS and TCS disagreeing on their
shared interface due to the lack of varying packing. In particular, it
was needed by Piglit's tcs-input-read-array-interface test.
However, that was just one case where things could go awry, so the
previous commit forcibly made interfaces match. This hack is no longer
necessary.
It also seems to be broken, though I'm not sure why. It fixes Piglit
regressions in spec/arb_shader_image_load_store/semantics from commit
ec1f159ac8.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98893
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
A while ago, I made i965 start compiling shaders independently. The VUE
map layouts were based entirely on each shader's input/output bitfields.
Assuming the interfaces match, this works out well - both sides will
compute the same layout, and outputs are correctly routed to inputs.
At the time, I had assumed that the linker would guarantee that the
interfaces match. While it usually succeeds, it unfortunately seems
to fail in some cases.
For example, Piglit's tcs-input-read-array-interface test has a VS
output array with two elements, but the TCS only reads one. The linker
isn't able to eliminate the unused element from the VS, which makes the
interfaces not match.
Another case is where a shader other than the last writes clip/cull
distances. These should be demoted to ordinary varyings, but they
currently aren't - so we think they still have some special meaning,
and prevent them from being eliminated.
Fixing the linker to guarantee this in all cases is complicated. It
needs to be able to optimize out dead code. It's tied into varying
packing and other messiness. While we can certainly improve it---and
should---I'd rather not rely on it being correct in all cases.
This patch ORs adjacent stages' input/output bitfields together,
ensuring that their interface (and hence VUE map layout) will be
compatible. This should safeguard us against linker insufficiencies.
Fixes line rendering in Dolphin, and the Piglit test based on it:
spec/glsl-1.50/execution/geometry/clip-distance-vs-gs-out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97232
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We would really like it to be false as that's what you get on hardware that
doesn't have RegisterPoleMode (Sky Lake for example). While we're at it,
we change it to a boolean. This fixes dEQP-VK.synchronization.smoke.events
on Broxton.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
LLVM can't really optimize anything which crosses scalar/vector boundaries,
so help a bit with some particular gather operations when the width is
expanded (only do it for 16->32bit expansion for now), by doing expansion
after fetch. That is probably a better solution anyway even if llvm would
recognize it, makes for cleaner IR...
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Note that we really want to _never_ reach the bottom of the function, which
resorts to AoS fetch.
Half floats can be handled just like other formats which fit into 32bit
vectors (so, only 1x16 and 2x16 formats, albeit with more channels things
are not THAT bad), with minimal plumbing. I've seen code size go down nearly
by a factor of 3 for a complete texture sampling function (including bilinear
filtering) using R16F.
(What we should do for everything not special cased is to do AoS gather,
shuffle/shift things into SoA vectors, and then do the conversion there.
Otherwise it's particularly bad with 1 or 2 channel formats - that r16f
format with either 4 or 8-wide vectors was still doing one element at a
time, essentially doing exactly the same work as for rgba16f. Also replacing
the channels with SWIZZLE0/1 (particularly the latter) adds even more
work, as it has to be done per aos vector, and not just straightforward
at the end with the SoA vector.)
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The PRMs for HSW and newer say that other than the opcode and DebugCtrl
bits of the instruction word, the rest must be zero.
By zeroing the instruction word manually, we avoid using any of the
state inherited through brw_codegen.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96959
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Allocating zero URB space is a really bad idea. The hardware has to
give threads a handle to their URB space, and threads have to use that
to terminate the thread. Having it be an empty region just breaks a
lot of assumptions. Hence, why we asserted that it isn't possible.
Unfortunately, it /is/ possible prior to Gen8, if max_vertices = 0.
In theory a geometry shader could do SSBO/image access and maybe
still accomplish something. In reality, this is tripped up by
conformance tests.
Gen8+ already avoids this problem by placing the vertex count DWord
in the URB entry header. This fixes things on earlier generations.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
As per GL 4.5 rules, which fixed a spec mistake in GL_ARB_stencil_texturing.
The extension spec wasn't updated, but just allow it with older GL versions
as well, hoping there aren't any crazy tests which want to see an error
there... (Compile tested only.)
Reported by Józef Kucia <joseph.kucia@gmail.com>
Acked-by: Józef Kucia <joseph.kucia@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Trivial, this just resurrects the code which was there once upon a time
(the code can't lower instructions generated in the lowering pass there,
and even if it could it would probably be suboptimal).
This fixes piglit mesa_shader_integer_functions fs-ldexp.shader_test and
vs-ldexp.shader_test with llvmpipe.
Reviewed-by: Matt Turner <mattst88@gmail.com>
All of these are happily set from glsl_to_nir or spirv_to_nir but their
values are never used for anything.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Constant initializers have been a constant (ha!) pain for quite some time.
While they're useful from a language perspective, people writing passes or
backends really don't want deal with them most of the time. This commit
removes most of the constant initializer support from NIR. It is expected
that you call nir_lower_constant_initializers VERY EARLY to ensure that
they're gone before you do anything interesting.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
It's only ever called on single-function shaders. At this point, there are
a lot of helpers that can make it all much simpler.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
When I originally implemented the ARB_copy_image extension, the fast-path
was written in meta using texture views. This path only worked if both
images were uncompressed color images. All of the other cases fell back to
the blitter or, in the worst case, mapping and memcpy on the CPU. Now that
we have the blorp path, it handles all copies ever and the old meta,
blitter, and CPU paths are only used on gen5 and below. The primary reason
why we needed the meta path (apart from having a slow blitter on later
hardware) was to handle multisampling which gen5 and earlier don't support
anyway. Since the blitter is reasonably fast on gen5, we can just delete
the meta path and get rid of all that terrible code.
If we decide that we're ok with just disabling ARB_copy_image on gen5 and
earlier (I personally am), then we could get rid of another 300 lines or so
of semi-hairy code.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
By using emit_miptree_blit which does chunking, this fixes the blitter path
for the case where the image is too tall to blit normally. We also pull it
into intel_blit as intel_miptree_copy. This matches the naming of the
blorp blit and copy functions brw_blorp_blit and brw_blorp_copy.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "13.0" <mesa-dev@lists.freedesktop.org>
This moves the nir_lower_indirect_derefs() call into
brw_preprocess_nir() so thats is called by both OpenGL and Vulkan
and removes that call to the old GLSL IR pass
lower_variable_index_to_cond_assign()
We want to do this pass in nir to be able to move loop unrolling
to nir.
There is a increase of 1-3 instructions in a small number of shaders,
and 2 Kerbal Space program shaders that increase by 32 instructions.
Shader-db results BDW:
total instructions in shared programs: 8705873 -> 8706194 (0.00%)
instructions in affected programs: 32515 -> 32836 (0.99%)
helped: 3
HURT: 79
total cycles in shared programs: 74618120 -> 74583476 (-0.05%)
cycles in affected programs: 528104 -> 493460 (-6.56%)
helped: 47
HURT: 37
LOST: 2
GAINED: 0
Use llvm provided API based on cpuid rather than our own
manually mantained list of mattr enabling/disabling.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
And declare coded_buf in vlVaContext as "vlVaBuffer *" instead of
"struct vlVaBuffer *".
This fixes several warnings later about assignment from incompatible
pointer type.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Remove some transitional left overs from the gallium pipe-loader rework
and kill off unneeded AM_CPPFLAGS.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This makes sure that we handle LLVM minor version >= 10 correctly.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Major and minor version are included in the header file since LLVM
version 3.1.0. Since the minimal required version is 3.3.0 we can
remove the workaround if no values for major/minor were found in the
header.
Since LLVM 3.6.0 the patch version is inside the header file of LLVM.
Only radeon drivers need the patch version and they depend on
LLVM >= 3.6.0, so this is safe too.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Consolidate the required LLVM versions at the top where the other
versions for dependencies are listed.
v5:
Splitted out separate changes (see patch 19 and 20)
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
LLVM components are only added when LLVM is needed.
This means gallium adds this as soon as "--enable-gallium-llvm"
is "yes" and radv + opencl add it explicitly.
v5:
Removed hunk that disabled LLVM for gallium if it was not found.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves the LLVM check for radv to the corresponding driver section.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves llvm_set_environment_variables to its final destination
and moves all the LLVM AC_SUBST() below the function call.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The LLVM checks can be anywhere below line 1161 now.
Move the openCL LLVM checks to the section with the other openCL checks.
No functional change.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
[Emil Velikov: s/ipos/ipo/, drop "yes" argument from llvm_add_component]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This moves the function to get the LLVM environment variables higher
in the file. It still needs to be below the "--enable-opencl" because
it uses $enable_opencl.
It can be called without condition now as it only throws errors if
openCL is enabled.
v5:
HAVE_MESA_LLVM is only used for gallium. Rename it to HAVE_GALLIUM_LLVM.
In order to only link LLVM when it is needed, HAVE_GALLIUM_LLVM is only
set if "$enable-gallium-llvm" is yes.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
No need for an additional function here.
Use the same style for LLVM checks as the other drivers
(e.g. r300, llvmpipe) that don't need a load of other checks.
Instead of open conding the LLVM version check, use the
function used by other drivers.
"enable_gallium_llvm" is checked by gallium_require_llvm().
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This moves the LLVM version check to the helper function
gallium_require_llvm() and uses the llvm_check_version_for() helper
instead of open conding the LLVM version check.
gallium_require_llvm is functionally the same as before, because
"enable_gallium_llvm" is only set to "yes" if the host cpu is x86:
if test "x$enable_gallium_llvm" = xauto; then
case "$host_cpu" in
i*86|x86_64|amd64) enable_gallium_llvm=yes;;
esac
fi
This function is also only called now when needed.
Before this patch llvmpipe would call this as soon as LLVM is
installed. Now it only gets called by llvmpipe if gallium
LLVM is actually enabled (i.e. only on x86).
Both reasons mentioned above remove the need to check host cpu
in the gallium_require_llvm function.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
