The semantics of discard differ between GLSL and HLSL and
their various implementations. Subsequently, numerous application
bugs occurred and SPV_EXT_demote_to_helper_invocation was written
in order to clarify the behavior. In NIR, we now have 3 different
intrinsics for 2 things, and while demote and terminate have clear
semantics, discard still doesn't and can mean either of the two.
This patch entirely removes nir_intrinsic_discard and
nir_intrinsic_discard_if and replaces all occurences either with
nir_intrinsic_terminate{_if} or nir_intrinsic_demote{_if} in the
case that the NIR option 'discard_is_demote' is being set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
The shifted offsets generated by ir3_nir_lower_io_offsets are not always
optimized well by nir_opt_offsets. If the offset to be shifted has the
form "iadd constant, foo" don't shift the result but transform it to
"iadd constant>>shift, (ushr foo, shift)". This ensures nir_opt_offsets
(which only looks for iadds) can fold the constant into the immediate
offset.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
Add the BASE index to the load/store_ssbo_ir3 intrinsic to store an
immediate offset. This offset is encoded in the corresponding fields of
isam.v/ldib.b/stib.b.
One extra optimization is implemented: whenever the regular offset is
also a constant, the total offset (regular plus immediate) is aligned
down to a multiple of the max immediate offset and this is used as the
regular offset while the immediate is set to the remainder. This ensures
that the register used for the regular offset can often be reused among
multiple contiguous accesses.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
Since a7xx, isam.v can be used to perform multi-component SSBO loads.
Use this whenever possible to prevent excessive scalarization. isam.v
also uses only a single coordinate (as opposed to a 2-dimensional
coordinate for isam) so this reduces register pressure as well.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
isam.v is a version of isam that can load multiple components from IBOs.
It uses some bits that are used for different purposes in other tex
instructions:
- bit 50 (.v): .s elsewhere
- bit 53 (indicates whether an immediate offset is used): .p elsewhere
- bit 18 (.1d when not set, has to be set for .v): 0 elsewhere
For this reason, the bitset hierarchy for cat5 had to be reordered a
bit.
The immediate offset is encoded as an extra (immed) source register and
an instruction flag (to be able to make the distinction between offset
zero and no offset, although this might not be useful).
This also adds a flag for the .1d field. Since this bit is active-low,
this flag has inverted semantics: setting it will make .1d inactive.
Note that some existing disassembler tests for isam had to be updated
because the bit is never set and this is now disassembled as .1d. This
matches the blob's disassembler.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
Having zero consts in one FS may corrupt consts in follow up FSs,
on such GPUs blob never has zero consts in FS. The mechanism of
corruption is unknown.
Fixes geometry flickering in a number of games, including:
Baldur's Gate 3
Assasin's Creed Rogue
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29357>
Copying UBWC image via BLIT_OP_SCALE may be corrupted if previously
someone copied image with bit 18 set in TPL1_DBG_ECO_CNTL1.
Found by replaying blob's cmdstream on a740, but somehow this issue
doesn't happen on Android.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29358>
For A6XX it's a no-op, but A7XX+ doesn't clamp to [0,1] with disabled
depth clamp, to support VK_EXT_depth_clamp_zero_one we have to always
enable clamp and manually set depth range to [0,1] when rs->depth_clamp_enable
is false.
Passes:
dEQP-VK.depth.*
dEQP-GLES3.functional.fbo.depth.depth_test_clamp.* (zink)
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29387>
This register stores the depth format of the underlying depth
buffer, it seemingly doesn't change anything about the LRZ buffer
itself and has no behavioral changes over setting it to 0.
However, it's possible that there's some case where it does matter
so matching the proprietary driver's behavior is safer.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29453>
With AHB + external format, we might get VK_FORMAT_UNDEFINED. And at
least with skiavk we might not get a chained VkExternalFormatANDROID.
In this case, just take the format from the image, which will have
already been resolved via VkExternalFormatANDROID when the image was
created.
See VUID-VkImageViewCreateInfo-image-02399
Also see commit 4f7de83110 ("venus: fix view format for ahb image")
for a similar fix.
Fixes the following cts tests:
CtsViewTestCases:
- android.view.cts.PixelCopyTest#testVideoProducer
CtsMediaDecoderTestCases:
- android.media.decoder.cts.DecodeAccuracyTest#testSurfaceViewLargerWidthDecodeAccuracy[50(c2.v4l2.avc.decoder_h264_520x360)]
- android.media.decoder.cts.DecodeAccuracyTest#testSurfaceViewLargerWidthDecodeAccuracy[50(c2.v4l2.avc.decoder_h264_520x360)]
CtsCameraTestCases:
- android.hardware.camera2.cts.MultiViewTest#testTextureImageWriterReaderOperation[1]
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29490>
We ran into an issue with Intel drivers where it became tricky to tell
whether a timestamp must be recorded with a special end-of-pipe
compute instruction or something else.
We initially tried to deal with that internally by checking some state
in the command buffers but turns out it doesn't work.
This change adds a flag field to the tracepoint to have that
information there and the flags are passed to the record_ts vfunc.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29438>
Alyssa Rosenzweig