This was uninitialized, which resulted in weird looking printouts where
it appeared that the TCS output and TES input patch URB entries differed
in SSO/non-SSO layout. There is no "separable" layout for both, as
they're tied together.
It should have no other actual effect.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Noticed while adding support for 64-bit integer types.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
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>
