We should not scrub raster dedicated states when dynamic state includes
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE.
Test:
- dEQP-VK.pipeline.extended_dynamic_state.*_raster
- dEQP-VK.api.pipeline.pipeline_invalid_pointers_unused_structs.graphics
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17582>
zink_kopper_acquire_readback will flush any outstanding clears, this means that
the current clears need to be applied first before calling zink_kopper_acquire_readback.
This was already done for native_blit and native_resolve, also do this for the emulated draw path.
Seen as intermittent failures in cts case GTF-GL33.gtf21.GL2FixedTests.buffer_clear.buffer_clear.
Cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17631>
Spirv spec does not allow the use of OpEmitVertex or OpEndPrimitive when there are multiple streams.
Instead emit the multi-stream version of these with stream set to 0.
This issue was seen when testing cts case KHR-GL46.transform_feedback.draw_xfb_stream_test
Fixes: 35e346f428 ("zink: handle vertex streams")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17513>
When we made depth/stencil dynamic, we lost the optimization. This is
particularly important for cases where the stencil test is enabled but
never writes anything as certain combinations with discard can cause
the stencil write (which doesn't do anything) to get moved late which
can be a measurable perf hit. According to 028e1137e6 ("anv/pipeline:
Be smarter about depth/stencil state", it was a couple percent for DOTA2
on Broadwell back in the day. No idea how it affects current titles.
This may also improve the depth/stncil PMA workarounds on Gen8 and Gen9
since they're now looking at optimized depth/stencil state.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
Now that we've stopped trying to do dynamic stuff up-front, we're only
merging in one bit: DoubleSidedStencilEnable. There's no point in all
the merging code for one bit which is a constant anyway.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
For one thing, we were deceptively setting it wrong in genX_cmd_buffer.c
and then overwriting it in each of of gfx7_cmd_buffer.c and
gfx8_cmd_buffer.c. Pull it all into genX_cmd_buffer.c so it's no longer
duplicated. Also, stop doing the PATCHLIST conversion in anv_pipeline.c
and just store the number of patch vertices.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
This attempts to be a pretty minimal refactor. We just switch all the
state emit code to use the new graphics pipeline state object.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
Following our rule that anything that can be dynamic should be set
(and is this case is already) in the following files :
- genX_cmd_buffer.c
- gfx8_cmd_buffer.c
- gfx7_cmd_buffer.c
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
The only reason why we recorded them per-sample-count is because Intel
hardware is weird starting with Broadwell. The API, requires that the
dynamic sample pattern be reset every time the sample count changes so
we only need to record the pattern for the current sample count.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
There's no good reason to defer figuring out the size until we emit the
packet. We know everything when the bind happens.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17564>
If the driver can do 16-bit ALU ops, then store RelaxedPrecision phi
values into 16-bit NIR variables with downconverts/upconverts on the way
in/out.
This has no impact on shader-db on freedreno (not that we have a ton of
GLES content there), but it does cause an ANGLE-translated CTS shader on
vulkan to get consistent conversions between two copies of a value, and
avoid a test bug.
Reviewed-by: Emma Anholt <emma@anholt.net>
Closes: #6585
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14018>
It seems that we sometimes stall out executing "fastboot boot", and if
that happens we want to reboot the board and try again.
Fixes: #6682
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17607>
This can't do it in the loop because it doesn't easily know what
attributes use a binding.
We could do it in a separate loop, but there's no point, especially since
zink does CmdSetVertexInputEXT() after CmdBindVertexBuffers2().
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Fixes: c335a4d70e ("radv: dynamically calculate misaligned_mask for dynamic vertex input")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17521>
We can't do uniform buffer objects and from the hardware
perspective constants (uniforms) and immediates are treated in
the same way. They are uploaded together and fit together into the
(rather low) total constant limit. Therefore, there is actually no
advantage in converting immediates to uniforms, and a whole lot of
disadvantages (less possible optimizations and no inlining).
Fixes the dEQP regressions from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16770
The tests failed because when there is an indirect array access the
compiler inserts a big if ladder and converting the temp to a uniform
means more instructions because the ifs cant be lowered at least
partially to selects. It is particularly visible, because the code
NIR currently emits for the indirect access doesn't really fit the
hardware, see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6366
No change in my shader-db, so this concerns the tests only.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17576>
This implements the "tortoise and the hare" algorithm for detecting
cycles in graphs. We use the caller's iterator as the hare and our own
internal copy as the tortoise. Conveniently, VkBaseOutStructure (and
VkBaseInStructure which is identical except the pointer type on pNext)
have a pointer we can use for the tortoise and an sType which we can use
for a counter to ensure we only increment the tortose every other loop
iteration.
There are more efficient algorithms than tortoise and hare but they
require allocating memory for something like a hash set of seen nodes.
Since this for debug purposes only, it's ok for it to be a bit
inefficient in the case where it hits the assert. In the usual case of
no loops, it's the same runtime efficiency as the unchecked version
except that it does a tiny bit of math and 50% more pointer chases.
Version 1 worked fine with clang and with GCC 12.1 with -O0 but not with
optimizations. See https://gitlab.freedesktop.org/mesa/mesa/-/issues/6895.
Unfortunately, the first version required modifying a temporary declared
const inside the for loop and that seems to have been the problem. This
version instead has an iterator struct which is managed by an outer for
loop and the inner for loop exists to declare the user's requested
iteration variable and manage the actual iteration. Because the outer
for loop is effectively `for (bool done = false; !done; done = true)`,
it will execute exactly once, regardless of the inner loop, so break and
continue inside the inner loop should work the same as if it's a single
for loop.
The other major difference with the new version is that the code is the
same for debug and release except the half_iter and loop check are gone.
I've verified by hand that this produces virtually identical code to the
old simple iterators on both GCC andl clang with an optimized build.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17630>
We're about to make it so that the compiler warns/errors if you use the
wrong iterator macro. Fix up a bunch of places where someone used the
wrong one before we break anything.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17630>
Instead of having stencil writes as an out parameter of the optimization
function, we add a new write_enable field for stencil that's equivalent
to the similarly named field for depth. This doesn't mean drivers must
actually support disabling stencil writes independently but the
information may be helpful on some hardware.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17328>
Otherwise, in presence of p_exit_early_if the main FS will always
jump to the PS epilog regardless the exact mask.
This fixes dEQP-VK.draw.renderpass.shader_invocation.helper_invocation
and few vkd3d-proton regressions when PS epilogs are forced.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17617>
Because the data register of atomic VMEM instructions
is shared between src and dst, it might be necessary
to create live-range splits during RA.
Make the live-range splits explicit in WQM mode.
Totals from 7 (0.01% of 134913) affected shaders: (GFX10.3)
Latency: 17209 -> 17210 (+0.01%)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15347>
When the application uses depth values outside of the [0.0,1.0] range
with VK_EXT_depth_range_unrestricted, or when explicitly disabled.
Otherwise, the driver can clamp to [0.0,1.0] internally for optimal
performance.
From the Vulkan spec "in 28.10.1. Depth Clamping and Range Adjustment":
"If depth clamping is not enabled and zf is not in the range [0, 1]
and either VK_EXT_depth_range_unrestricted is not enabled, or the
depth attachment has a fixed-point format, then zf is undefined
following this step."
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16349>
This feature allows shaders to use pointers to buffers which may
not be bound via descriptor sets. Access to these buffers is done
via global intrinsics.
Because the buffers are not accessed through descriptor sets, any
live buffer flagged with VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR
can be accessed by any shader using global intrinsics, so the driver
needs to make sure all these buffers are mapped by the kernel when
it submits the job for execution.
We handle this by tracking if any draw call or compute dispatch in
a job uses a pipeline that has any such shaders. If so, the job is
flagged as using buffer device address and the kernel submission
for that job will add all live BOs bound to buffers flagged with the
buffer device address usage flag.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17275>
This adds support for global 64-bit GPU addresses as a pair of
32-bit values. This is useful for platforms with 32-bit GPUs
that want to support VK_KHR_buffer_device_address, which makes
GPU addresses explicitly 64-bit.
With the new format we also add new global intrinsics with 2x32
suffix that consume the new address format.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17275>
