Section 11.2.6 of the Vulkan spec states:
"Importing memory from a particular host pointer may not be possible due to
additional platform-specific restrictions beyond the scope of this
specification in which case the implementation must fail the memory
import operation with the error code VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17995>
This experimental and very suboptimal implementation of graphics
pipeline library shouldn't be used by anyone, except for development
purposes. It's still under active development from my side. This
extension is only exposed via RADV_PERFTEST=gpl anyways.
It's very suboptimal because RADV doesn't yet support PS epilogs and
VS prologs need to be improved/reworked because GPL changed the logic
(eg. can't know the next stage when compiling a prolog). So, currently
the driver ALWAYS retains NIR shaders during libs creation and it links
and compiles in the final pipeline.
I have WIP branches for approximately everything but it looks simpler
to start merging an initial implementation in order to improve steps
by steps from main. This commit might look simple and short but I
already merged TON of preliminary work. RADV was definitely not ready
for GPL and it's still not completely fine. Expect refactoring again.
This implementation currently pass
dEQP-VK.pipeline.pipeline_library.* on NAVI21, except few feedback
creation tests due to CTS bugs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
For gfx pipeline libraries we would have to keep track of the gfx
state, so change how it's allocated.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
It currently inherits from radv_graphics_pipeline because it's simpler
but I think it could be improved because most of fields won't be useful
for libs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
It also initializes dynamic states and active stages. It will also be
used when creating a graphics pipeline library.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17542>
It isnt used anymore, last used in tu_wsi_display.c which doesnt
exist anymore.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17927>
The majority of the logic here was for the Gfx8-9 sample-from-hiz
hardware feature, which only applies to AUX_USAGE_HIZ, and neither
of the combined HiZ+CCS modes. So, reorganize the function to put
the logic for each case in the case itself.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
When using HIZ_CCS_WT, we always want to use that for texturing so that
we're able to sample from the CCS buffer, which will have the latest
data due to the write-through mode.
With the previous commit in place, HiZ now exists for all miplevels
on platforms which support HIZ_CCS_WT, so we no longer need the
per-miplevel checks.
The other restrictions in this function only apply to the Gfx8-9 feature
where the sampler directly supported reading from HiZ itself, which was
removed. Hardware where HiZ and CCS can be used together doesn't have
that feature nor its restrictions.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4952
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
8x4 alignment was absolutely required prior to Gfx8, and while some
things were relaxed on Gfx8-9, Nanley's experiments in issue #3788
indicated that there were still issues on those platforms.
It appears that the restrictions were relaxed on Icelake and
non-8x4 aligned HiZ "should" work on Gfx11+.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4674>
When you're debugging some deqp test or app, it's irritating to page
through 8 MRT clear shaders in turnip to get to what you're looking for.
Use the info.internal flag to suppress those shaders. (but if you want to
IR3_SHADER_DEBUG=internal, then yeah, print them all).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18002>
device is allocated with vk_zalloc() that zeroes the allocated memory.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17961>
We can use I915_DEFINE_CONTEXT_PARAM_ENGINES() to simply the filling
of engines_param.
As some compilers might not support VLA, defining struct with 64
engines, the maximum that i915 API supports.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17961>
previously this would just destroy and recreate pools, but it's much
smarter to instead store the pools and just reuse them when needed
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18065>
this may use a little more memory, but having direct access to the pool
without needing a lookup in a (potentially big) hash table is definitely
worth it
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18065>
it's been long enough, and there's no technical reason why drivers
shouldn't have this implemented
ZINK_DESCRIPTORS environment variable is preserved for future use
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18065>
A situation where it doesn't match is probably not possible, so this
probably doesn't fix anything.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18077>
If this is true, then the only instruction the loops visit is
p_logical_end and the loops are no-ops.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18077>
We shouldn't remove a p_cbranch_nz branch in this situation.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: b731be2e96 ("aco: Remove branch instruction when exec is constant non-zero.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18077>
The isConstant() check isn't useful. If it's a constant, then the
physReg() check will fail.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: baab6f18c9 ("aco: Optimize branching sequence during SSA elimination.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18077>
We would assemble an instruction writing vcc instead.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 5ffc73896f ("aco/assembler: Fix v_cmpx with SDWA.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18077>
The old name is no longer accurate.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18077>
RADV supports VK_EXT_attachment_feedback_loop_layout now,
and DXVK is using since 63d582a6e7ab63e18503d1238101705a818f5ad0 which
will be in DXVK 2.0, so no need for these anymore.
Older versions of DXVK will still be affected by the issue however.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17920>
`tu_WaitForFences` and `tu_GetFenceStatus` ended up using `ioctl` instead of
`safe_ioctl` and as a result were responsible for handling `EAGAIN`/`EINTR`
but they weren't handled correctly in wait calls which led to dropping the
wait if the thread received a signal without automatic syscall restarting on
release builds and an assertion due to `errorno` being `EINTR` on debug
builds.
This fixes early wait returns which would lead to UB or cause crashes due to
hitting debug assertions in Skyline Emulator.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18031>
Similar to VK_KHR_buffer_device_address which has also been promoted
from EXT.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18061>
RADV now uses vk_graphics_pipeline_state from Vulkan common code which
is more convenient for eg. graphics pipeline libraries.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18015>
This also converts VkAttachmentSampleCountInfoAMD which is part of
vk_render_pass_state.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18015>
