With "classic" renderpasses, the VkFramebuffer's layerCount must be 1 if
multiview is enabled. We accidentally rely on this to not disable GMEM
for multiview, and possibly for other things too. Apparently the dynamic
rendering equivalent, VkRenderingInfo::layerCount, can be anything when
multiview is enabled, and some CTS tests set it to the number of views.
Sanitize it when constructing the internal framebuffer for dynamic
rendering.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34080>
We were a bit too conservative and fully disabled LRZ for when stencil
or blending were involved. There is no need to fully disable LRZ
in those cases, only LRZ writes should be disabled.
The final rules are:
LRZ is DISABLED until depth attachment is cleared when:
- Depth Write + changing direction of depth test
e.g. from OP_GREATER to OP_LESS;
- Depth Write + OP_ALWAYS or OP_NOT_EQUAL;
- Clearing depth with vkCmdClearAttachments;
- Depth image is a target of blit commands.
- (pre-a650) Not clearing depth attachment with LOAD_OP_CLEAR;
- (pre-a650) Using secondary command buffers;
LRZ WRITE is DISABLED until depth attachment is cleared when:
- Depth Write + blending (color blend, logic ops, partial color mask, etc.);
- Fragment may be killed by stencil;
LRZ is disabled for CURRENT draw when:
- Fragment shader side-effects (writing to SSBOs, atomic operations, etc);
- Fragment shader writes depth or stencil;
LRZ WRITE is DISABLED (via LATE_Z) for CURRENT draw when:
- Fragment may be via killed alpha-to-coverage, discard, sample coverage;
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33851>
This adds the latency information provided by NVIDIA. This is copied
from excel spreadsheets provided to Red Hat.
This fully passes CTS on Turing TU104 with no regressions.
I'm sure future use of some instructions like IMAD may require some
changes to this, but it should be functionally complete.
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
Delays greater than 15 needs to be encoded into a nop following the
instruction. These delays will start to happen when we add accurate
latency handling and with certain instructions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
Otherwise we schedule this sort of thing wrong,
r0 = iadd3 r0 c[0x0][0x0] rZ
r0 = shf.l.w.i32 r0 rZ 0x2
r0 p0 = iadd3 r0 c[0x1][0x0] rZ
since raw latencies are more important than waw, but we go do a
waw for the first two instructions instead of a raw which is correct.
Fixes: 2d4e445099 ("nak/calc_instr_deps: Rewrite calc_delays() again")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33573>
When we are using compute resolve, we can get
values the CTS does not expect due to the value
we end up writing for UNORM in
`nir_image_deref_store`.
Make the compute resolve rounding path match with
the output of the fragment shader resolve path,
by going through the same FP16 RTZ conversion as
we do for UNORM/SNORM formats.
This is why VK_EXT_sample_locations CTS was
failing on > GFX9.
On <= GFX9, I am assuming we are falling back to
RESOLVE_FRAGMENT, due to DCC stuff, which is why
it works there.
I tested a handful of images from the Vulkan CTS
for the sample locations and resolve tests for
diff UNORM formats from the qpa file forcing
FRAGMENT and with this change.
With this change, we now match on the compute
resolve path the same sha for the ones I compared
with ImageMagick `identify`.
CTS passes for: *resolve*, *image_clearing* and
*sample_locations* on RX 7900XTX.
Signed-off-by: Autumn Ashton <misyl@froggi.es>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28237>
This is based on Timur Kristof's code, but there are a lot of differences.
The idea is that it doesn't just compute an intersection between a point
and a triangle. It computes the *distance* between a point and a triangle
and it does so in screen space. It accurately takes the subpixel precision
of the rasterizer into account, so that it works optimally at all
resolutions, all MSAA modes, and all quant modes.
The distance computation is only approximated because it only considers
the infinite lines going through triangle edges. However, it seems to be
more than sufficient in practice because the existing rounding-based small
prim culling compensates for it.
The performance improvement is up to 10% in some geometry-bound tests,
though targeted microbenchmarks can show a lot more than that.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33361>
Migrate the panfrost-g52-vk job to mt8186-corsola-steelix-sku131072, a
new device in LAVA. This DUT is faster than the Khadas VIM3 device it
replaces, and since more of these devices are available in LAVA, reduce
the DEQP_FRACTION and increase the parallelism for the pre-merge job.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33996>
Eric Engestrom