This requires that we limit the number of max combinded SSBOs to 31,
otherwisewe shaders that use SSBO binding points with higher values
will break on the host.
Fixes CTS:
KHR-GL43.shader_storage_buffer_object.basic-atomic-case1
KHR-GL43.shader_storage_buffer_object.basic-atomic-case2
KHR-GL43.shader_storage_buffer_object.advanced-indirectAddressing-case2
KHR-GL43.shader_storage_buffer_object.advanced-usage-case1
KHR-GL43.shader_storage_buffer_object.advanced-usage-sync
KHR-GL43.shader_storage_buffer_object.advanced-matrix
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21586>
When a shader uses SSBOs in various shader stages, then we have to track
the binding locations in order to be able to properly bind these SSBOs.
Therefore add a flag that enables adding the start index of the bindings to
the SSBO index.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21586>
Blob resources are mapped directly, no need to copy data around, and
in any case, neither the resource nor the transfer info will have an
IOV attached to it, so the transfer would result error out on the host
anyway.
In addition, blob resources should not use re-allocation.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21586>
Rounding up the polygon list BO can waste large amounts of memory. In a common
case I observed, it rounded up 11MB to 16MB, wasting 5MB. That adds up quickly
across processes, especially on the 2GB machines.
This only applies to Midgard. On Bifrost and newer, the driver does not
explicitly allocate this data structure. Cc stable because this rounding is
incorrect and the increase in RAM usage can cause real problems (especially
given how slow the shrinker is).
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21831>
HSD 1306463417 is a hardware defect. The originating software
workaround for the issue is Wa_1409433168. Convert all references to
the software workaround number, and use generated helpers instead of
GFX comparisons.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21914>
The logic that updates `ctx->gfx_pipeline_state.final_hash` assumed that
the program is replaced. It is supposed to xor `final_hash` with the
hash first and then with the new hash however when the program is
updated it end up xor-ing the new hash twice so it does nothing.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Fixes: 15450d2c2e ("zink: incrementally hash all pipeline component hashes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21925>
Having driver name in the renderer will be useful to differentiate
between open source and proprietary drivers as they can have different
feature sets/quirks.
Vulkan API version is also added to the name to match up with ANGLE.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21922>
Indeed, ureg_get_tokens() returns an allocated string that should be
freed using ureg_free_tokens().
For instance, with "piglit/bin/arb_shader_image_load_store-invalid -auto -fbo"
Direct leak of 768 byte(s) in 2 object(s) allocated from:
#0 0x7fa819a78b48 in __interceptor_realloc (/usr/lib64/libasan.so.6+0xb1b48)
#1 0x7fa80e189e04 in tokens_expand ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:239
#2 0x7fa80e189e04 in get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:262
#3 0x7fa80e191f6e in copy_instructions ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2079
#4 0x7fa80e191f6e in ureg_finalize ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2129
#5 0x7fa80e19447b in ureg_get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2206
#6 0x7fa80ec68b91 in si_create_fmask_expand_cs ../src/gallium/drivers/radeonsi/si_shaderlib_tgsi.c:564
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21871>
Now that we don't do GLSL IR constant propagation or constant folding, we
can leave constant variable detection and handling to NIR. This also
avoids some OOB array access in GLSL IR in a piglit test!
Freedreno stats again look like noise:
total instructions in shared programs: 2718412 -> 2718746 (0.01%)
instructions in affected programs: 80497 -> 80831 (0.41%)
total last-baryf in shared programs: 110015 -> 110510 (0.45%)
last-baryf in affected programs: 35263 -> 35758 (1.40%)
total full in shared programs: 189486 -> 189480 (<.01%)
full in affected programs: 52 -> 46 (-11.54%)
total constlen in shared programs: 494540 -> 494496 (<.01%)
constlen in affected programs: 452 -> 408 (-9.73%)
total sstall in shared programs: 198297 -> 197928 (-0.19%)
sstall in affected programs: 3691 -> 3322 (-10.00%)
total systall in shared programs: 432150 -> 431799 (-0.08%)
systall in affected programs: 6070 -> 5719 (-5.78%)
total waves in shared programs: 435098 -> 435110 (<.01%)
waves in affected programs: 92 -> 104 (13.04%)
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21751>
The whole usage of this flag is to call iris_use_pinned_bo() with
writable argument, for that we don't need any i915_drm.h specific type.
IRIS_BLORP_RELOC_FLAGS_EXEC_OBJECT_WRITE could have any other value but
keeping the same as i915_drm.h.
With this we can drop 2 i915_drm.h imports from generic Iris code.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21887>
This is really dumb.
But this fixes arb_shader_language_420pack-active-sampler-conflict on v7 which
otherwise dereferences a null pointer trying to access the nonexistant texture
arrays, or DATA_INVALID_FAULTs if you give it a texture array filled with
zeroes. But it seems happy if you bind in null textures. This is dumb but less
faults in Piglit is good for reducing flakes.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21891>
draw->index_bounds_valid tells drivers that the values of min_index/max_index
are set correctly and can be used e.g. to allocate memory for varyings. If set
incorrectly, the GL promises badness.
But, with primconvert, we go mucking with index buffers and then never update
the bounds. So it doesn't matter if the original index bounds were valid, we
can't promise the original bounds are *still* valid. If we were trying to
optimize CPU overhead, we could try to preserve the new min/max index but seeing
as only older Mali cares about this flag, and if you're using primconvert you're
already screwed, I'm not too inclined to go rework primconvert.
Fixes* page faults in primitive-restart-draw-mode on Mali-G52 for GL_QUAD_STRIPS
and GL_POLYGON, which hit the primconvert path. The full dmesg splat looks like:
[ 5438.811727] panfrost ffe40000.gpu: Unhandled Page fault in AS0 at VA 0x000000100A16BAC0
Reason: TODO
raw fault status: 0x25002C1
decoded fault status: SLAVE FAULT
exception type 0xC1: TRANSLATION_FAULT_1
access type 0x2: READ
source id 0x250
Notice that a high bit is randomly set in the address, this is trying to read
a varying from the actual varying buffer in the vicinity of 0xa16bac0. What's
actually happening is that we're trying to read index #0 despite promising the
driver a minimum index of 2, causing an integer underflow as we try to read
index -2, or as the hardware sees, 4294967294.
As long as we stop lying to panfrost about the bounds being correct, panfrost is
able to calculate the real (post-primconverted) bounds on its own, fixing the
test.
* Alternatively, maybe Panfrost should just ignore this bit, in which I don't
know why we have it in Gallium, since it's probably not conformant to fault on
out-of-range glDrawRangeElements.
Fixes: 72ff53098c ("gallium: add pipe_draw_info::index_bounds_valid")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21891>
First make sure shadow mask change sets dirty state.
Second move shadow mask bit removal to unbind_samplerview which
is cleaner and correctly clears the shadow bit when binding buffer texture.
Fixes: 5193f4f712 ("zink: add a fs shader key member to indicate depth texturing mode")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21571>
