It can happen that we create an enormous merge set, even larger than the
entire register file, in which case find_best_gap() would loop
infinitely. This seems to be triggered more often with
IR3_SHADER_DEBUG=spillall, since it actually happened with a CTS test.
Just bail out in that case.
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
When we mark live-through sources that are merged with the destination
as killed, we kept the bitsets in sync, but we forgot to keep them in
sync when unmarking them after allocating the destination. The result
was that "available" wasn't correct for any instruction afterwards. This
resulted in a bad register allocation with IR3_SHADER_DEBUG=spillall for
a dEQP-VK test.
While we're changing this, use ra_foreach_src().
Fixes: 0ffcb19b9d ("ir3: Rewrite register allocation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
Otherwise when an interval is removed and then re-inserted it could
have an invalid/corrupted parent link and child tree. I think RA
happened to never do this, but spilling will.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12033>
Floats have much better precision close to zero than close to one, so
let's make sure we compute an interpolation factor that goes in the
direction that discards the fewest bits.
This makes a big difference when interpolating from very small to very
large values for screen-space positions.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12355>
By checking the output images against the reference ones on the failed
trace jobs, I looked for artifacts via naked eye and image diffs. No
significant change was found. So the trace produced by the failed jobs
can be considered valid.
Updated devices' traces:
* Intel Comet Lake: iris-cml-traces
* Intel Gemini Lake: iris-glk-traces
* Intel Kaby Lake: iris-kbl-traces
* Intel Whiskey Lake: iris-whl-traces
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12394>
Fixes
dEQP-GLES2.functional.fbo.completeness.renderable.texture.color0.rgb10_a2 on
GLES2 drivers which support RGB10_A2 textures.
GL_OES_required_internalformat does not make it a color-renderable
format.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4972
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12464>
CTS draw_indirect usage of TFB output was flaking due to the TFB writes
possibly not having completed. Since GL TFB doesn't require any other
barrier between TFB and use of the BO (as seen by the CTS not emitting any
memory barrier), we have to do it ourselves.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12457>
There are a bunch of optimizations that are broken when DPP is involved.
fossil-db (Sienna Cichlid):
Totals from 100 (0.07% of 150170) affected shaders:
CodeSize: 325204 -> 325192 (-0.00%); split: -0.06%, +0.05%
Instrs: 62773 -> 62664 (-0.17%); split: -0.18%, +0.00%
Latency: 295348 -> 295266 (-0.03%); split: -0.03%, +0.00%
InvThroughput: 73990 -> 73946 (-0.06%); split: -0.06%, +0.01%
Copies: 1650 -> 1609 (-2.48%); split: -2.55%, +0.06%
PreSGPRs: 3554 -> 3520 (-0.96%)
Fossil-db changes are probably because v_sub_f32_dpp(v_mul_f32) is no
longer being combined into MAD and then split back into separate
instructions.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11924>
I haven't gone through every test (particularly ones I think are loop
unrolling or instruction-count-related ones I think), but this gives a
better picture of what's going on in this driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12436>
Fixes: 51935d59
temporal_id check is valid only if the num_temporal_layers is set (>0).
When num_temporal_layers is 0, we shouldn't check temporal_id and return
error.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12463>
Fixes: 51935d59
In the case where num_temporal_layers is not set (0), set it using the
minimum value 1, otherwise the rate control settings will be missing.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12463>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, implement the resource_get_param hook to allow users to
fetch this information without WINSYS_HANDLE_TYPE_KMS.
A tiny helper function is introduced to compute the modifier of a
resource.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7bcb223639 ("v3d, vc4: Fix dmabuf import for non-scanout buffers")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, implement the resource_get_param hook to allow users to
fetch this information without WINSYS_HANDLE_TYPE_KMS.
A tiny helper function is introduced to compute the modifier of a
resource.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 7bcb223639 ("v3d, vc4: Fix dmabuf import for non-scanout buffers")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, implement the resource_get_param hook to allow users to
fetch this information without WINSYS_HANDLE_TYPE_KMS.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 4c092947df ("panfrost: fail in get_handle(TYPE_KMS) without a scanout resource")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
Prior to this commit, the stride, offset and modifier were fetched
via WINSYS_HANDLE_TYPE_KMS. However we can't make such a query
succeed if the buffer couldn't be imported to the KMS device.
Instead, extend the resource_get_param hook to allow users to fetch
this information without WINSYS_HANDLE_TYPE_KMS.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 9da901d2b2 ("etnaviv: fail in get_handle(TYPE_KMS) without a scanout resource")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12370>
When this was rewritten to support Vulkan, we stopped initializing
file_max to -1 in the case of no inputs. This causes the draw module
to go down a needlessly pessimistic case, printing an error while we're
at it.
Fixes: 42b5cfdbd2 ("gallivm/nir: fix vulkan vertex inputs")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12440>
On some GPUs when:
- depth bounds test is enabled
- depth test is disabled
- depth attachment uses UBWC in sysmem mode
GPU hangs. As a workaround we should enable z test. That's what blob
is doing for a630. And since we enable z test we should make it always pass.
Blob doesn't emit this workaround on a650 and a660. Untested on a640.
Fixes:
dEQP-VK.pipeline.extended_dynamic_state.two_draws_static.depth_bounds_test_disable
dEQP-VK.pipeline.extended_dynamic_state.two_draws_dynamic.depth_bounds_test_disable
dEQP-VK.dynamic_state.ds_state.depth_bounds_1
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12407>
The OpenGL 4.6 specification, section 14.5.2.1 (Line Stipple) says:
> The masking is achieved using three parameters: the 16-bit line
> stipple p, the line repeat count r, and an integer stipple counter s.
This is pretty clear that the stipple counter shouldn't carry fractional
parts. But we also don't really do anything useful with the fractional
part anyway, apart from skewing the third or later line-segments
Properly carrying over the fractional parts as the Vulkan specification
allows for rectangular lines is trickier than this and would require us
to use a shorter output-line at the start of the following
line-segments.
But let's just do what the OpenGL specification describes, and the
Vulkan specification allows for now.
This, combined with the following patch for the vulkan CTS makes the
last two rasterization-tests pass for me:
https://github.com/KhronosGroup/VK-GL-CTS/pull/279
Fixes the "spec/!opengl 1.1/linestipple/line strip" piglit-test.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12327>
Changes:
- nir_metadata_preserve(..., nir_metadata_all) is called when pass doesn't
make progress
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12467>
Images that support comp-to-single don't have to be fast-cleared at
all, so the predicate is unnecessary.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12323>
