This commit moves us to an instruction based model rather than a
register-based model for indirects. This is more accurate anyway as we
have to emit instructions to resolve the reladdr. It's also a lot simpler
because it gets rid of the recursive reladdr problem by design.
One side-effect of this is that we need a whole new algorithm in
move_uniform_array_access_to_pull_constants. This new algorithm is much
more straightforward than the old one and is fairly similar to what we're
already doing in the FS backend.
Now that we have MOV_INDIRECT opcodes, we have all of the size information
we need directly in the opcode. With a little restructuring of the
algorithm used in assign_constant_locations we don't need param_size
anymore. The big thing to watch out for now, however, is that you can have
two ranges overlap where neither contains the other. In order to deal with
this, we make the first pass just flag what needs pulling and handle
assigning pull constant locations until later.
Instead of using reladdr, this commit changes the FS backend to emit a
MOV_INDIRECT whenever we need an indirect uniform load. We also have to
rework some of the other bits of the backend to handle this new form of
uniform load. The obvious change is that demote_pull_constants now acts
more like a lowering pass when it hits a MOV_INDIRECT.
This is a newer convention, which we prefer over ALIGN(x, n) / n.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
The compact VUE map only works when varying packing is in use.
Unfortunately, varying packing is disabled for TCS inputs.
This is needed to fix Piglit's tcs-input-read-array-interface test.
v2: Make lines fit in 80 columns (caught by Jordan Justen).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
TCS outputs and TES inputs both refer to a common "patch URB entry"
shared across all invocations. First, there are some number of
per-patch entries. Then, there are per-vertex entries accessed via
an offset for the variable and a stride times the vertex index.
Because these calculations need to be done in both the vec4 and scalar
backends, it's simpler to just compute the offset calculations in NIR.
It doesn't necessarily make much sense to use per-vertex intrinsics
afterwards, but that at least means we don't lose the per-patch vs.
per-vertex information.
v2: Use is_input/is_output helpers (suggested by Jordan Justen).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
TES outputs work exactly like VS outputs, so we can simply add a case
statement for those.
TCS inputs are very similar to geometry shaders - they're arrays of
per-vertex data. We use the same method I used for the scalar GS
backend.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Without varying packing, if a VS writes a compound variable, and the GS
only reads part of it, the base location of the variable may not
actually be in the VUE map.
To cope with this, we do lowering in terms of varying slots, add any
constant offsets to the base, and then do the VUE map remapping. This
ensures we only look up VUE map entries for slots which actually exist.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
My tessellation branch has two additional remap functions. I don't want
to replicate this logic there.
v2: Handle inputs/outputs separately (suggested by Jason Ekstrand).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
While we're at it, we also add support for the possibility that the
indirect is, in fact, a constant. This shouldn't happen in the common case
(if it does, that means NIR failed to constant-fold something), but it's
possible so we should handle it.
Shared variables and input reworks landed around the same time.
Presumably, this was some sort of mistake in rebase conflict resolution.
This really only affects the num_indices field in nir_intrinsic_infos,
which is rarely used. However, it's used by the printer.
Found by inspection.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This is what image_view does. Also, we really need to do this so that we
can properly handle the combined offsets from the buffer and from
pCreateInfo.
This fixes some of the nonzero offset buffer view CTS tests.
GL_DRAW_FRAMEBUFFER does not exist in OpenGL ES 1.x, and since
_mesa_meta_begin hasn't been called yet, we have to work-around API
difficulties. The whole reason that GL_DRAW_FRAMEBUFFER is used instead
of GL_FRAMEBUFFER is that the read framebuffer may be different. This
is moot in OpenGL ES 1.x.
I have another patch series that would also fix this (by removing the
calls to _mesa_BindFramebuffer and friends), but it's not quite ready
yet... and I think it may be a bit heavy for some stable branches.
Consider this a stop-gap fix.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93215
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
When building RENDER_SURFACE_STATE, the driver set
SurfaceType = anv_image::surface_type, which was calculated during
anv_image_init(). This was bad because the value of
anv_image::surface_type was taken from a gen-specific header,
gen8_pack.h, even though the anv_image structure is used for all gens.
Replace anv_image::surface_type with a gen-specific lookup function,
anv_surftype(), defined in gen${x}_state.c.
The lookup function contains some useful asserts that caught some nasty
bugs in anv meta, which were fixed in the previous commit.
Meta unconditionally used VK_IMAGE_VIEW_TYPE_2D in the functions below.
This caused some out-of-bound memory accesses.
anv_CmdCopyImage
anv_CmdBlitImage
anv_CmdCopyBufferToImage
anv_CmdClearColorImage
Fix it by adding a new function, anv_meta_get_view_type().
Regarding the subimages within a surface, sometimes isl called them
"images" and sometimes "LODs". This patch make isl consistently refer to
them as "images". I choose the term "image" over "LOD" because LOD is
an misnomer when applied to 3D surfaces. The alignment applies to each
individual 2D subimage, not to the LOD as a whole.
This patch changes no behavior. It's just a manually performed,
case-insensitive, replacement s/lod/image/ that maintains correct
indentation. any behavior.
Remove unused variables from clear_state and use a hardcoded location
for color uniform to get rid of 2 more variables. Modify shaders to use
explicit location for vertex attribute too as extension is enabled.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
GRID Autosport uses SSO shaders. When a tessellation evaluation shader
is passed through this, it triggers assertion failures down the line
with unassigned varying locations. Make sure to do this when the first
shader in the pipeline is not a vertex shader.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Previously if the visual didn't have an alpha channel then it would
pick a format that is not sRGB-capable. I don't think there's any
reason not to always have an sRGB-capable visual. Since 28090b30 there
are now visuals advertised without an alpha channel which means that
games that don't request alpha bits in the config would end up without
an sRGB-capable visual. This was breaking supertuxkart which assumes
the winsys buffer is always sRGB-capable.
The previous code always used an RGBA format if the visual config
itself was marked as sRGB-capable regardless of whether the visual has
alpha bits. I think we don't actually advertise any sRGB-capable
visuals (but we just use sRGB formats anyway) so it shouldn't make any
difference. However this patch also changes it to use RGBX if an
sRGB-capable visual is requested without alpha bits for consistency.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92759
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
brw_init_surface_formats overrides the render format for RGBX formats
which aren't supported for rendering so that they internally use RGBA
instead. However, B8G8R8X8_SRGB was missing so it wasn't marked as a
renderable format. This patch just adds it.
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Our hardware requires an LOD for all texelFetch commands even if they are
on buffer textures. GLSL IR gives us an LOD of 0 in that case, but the LOD
is really rather meaningless. This commit allows other NIR producers to be
more lazy and not provide one at all.
With the current algorithm, we only look at tex uses. However there's a
write-after-write hazard where we might decide to, on some path, not use
a texture's output at all, but instead to write a different value to
that register. However without the barrier, the texture might complete
later and overwrite that value.
This fixes Unreal Elemental demo on GK110/GK208, flightgear on GK10x,
and likely other random-looking failures.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
In some cases shaders want non-default rounding when converting float to
integer. This can be done in one go, so merge the two ops. This comes up
in the packUnorm4x8 & co functions, as well as a few random shaders.
Overall shader-db impact is minimal, helping a handful of witcher2 and
other misc shaders.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
The conversion of 32-bit integer multiplies into 16-bit ones happens
after the regular optimization loop. However it's fairly common to
multiply by a small integer, rendering some of the expansion pointless.
Firstly, propagate immediates when possible into mul ops, secondly just
remove the ops when they are unnecessary.
Including the change to generate imad immediates, the effect is:
total instructions in shared programs : 6365463 -> 6351898 (-0.21%)
total gprs used in shared programs : 728684 -> 728684 (0.00%)
total local used in shared programs : 9904 -> 9904 (0.00%)
total bytes used in shared programs : 44001576 -> 44036120 (0.08%)
local gpr inst bytes
helped 0 0 3288 4
hurt 0 0 0 842
It's easy for this to hurt bytes since we end up always generating the
8-byte form, while we can't always get rid of the immediate in question.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
There will usually be a split before the mad op, peer through that and
pick out the right word of the immediate.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
