gp has explicit load and store reg instructions so it can implement
the new nir_intrinsic_{decl,load,store}_reg intrinsics.
The implementation reuses the gpir_node_find and register_node functions
instead of just emitting load and store instructions in order to
preserve the behavior that there will never be a store_reg followed by
a load_reg of the same register in the same block.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24246>
With the upcoming transition away from nir_register and modifiers in
nir, ppir needs to prepare for those features to be removed.
The most straightforward way for ppir without major reworks at this time
is to use the new nir_legacy helpers so that most of the backend can be
kept untouched (particularly due to use of abs/neg/sat modifiers).
Do this for now to unblock the transition with little impact; ppir can
be optimized at a later moment to have its own passes which will allow
it to drop the nir_legacy use and use just the chasing helpers.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24246>
Even if loads are initially duplicated for each user, with new
optimizations such as folding modifiers, it may happen that loads
end up with only users in different blocks.
Handle that and don't delete or pipeline those nodes.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24246>
ffloor(f2i(x)) can't be optimized to f2i(x) due to differing behaviour for
negative x, but u_blitter only uses this with nonnegative x so we can instead
use ftrunc(f2i(x)) which NIR will optimize to f2i(x) for us. This gets rid of
the silly ffloor instructions in blit shaders.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24319>
This dri config is no longer necessary since the case where it was
required is being handled in the previous commit.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24222>
When we try to run a compositor on top of Zink, we hit a lockup
when enumerating the Vulkan devices. The vulkan_device_select
tries to reorder the devices and gets stuck waiting for the Xserver.
With this patch, we avoid this issue by detecting when we are running
a compositor and disabling the X and Wayland instance extensions.
And code is added to try to pick the same device as the display.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24222>
Xe KMD only requires userptr to be bound to VM, so here returning
UINT32_MAX as gem_handle in Xe version of gem_create_userptr() for all
userptr bos.
As no bo is created it was also necessary to add additional handling
to xe_gem_close().
The vm bind side of userptr was already implemented, so it was only
necessary add the special handling and the kmd vm bind call.
This fixes piglit@amd_pinned_memory subtests that makes uses of
userptr.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23817>
Xe support of userptr will be implemented in the next patch,
this is just moving the i915 function to KMD backend.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23817>
The next patch will need a special handling when closing userptr bos
in Xe KMD, so here moving iris_bufmgr_bo_close() to kmd backend
and changing the gem_handle parameter to iris_bo.
There still one DRM_IOCTL_GEM_CLOSE call left in iris_bufmgr, that
is used to close exported gem handles.
iris_bufmgr_get_for_fd() could be used to get the iris_bufmgr but
we would still have problems with bo_export != iris_bo, so leaving
as is until a better solution is found.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23817>
This was being called from the common code, so it was being executed
for Xe KMD.
Luckily Xe don't have any uAPI at 0x1f offset.
There is still one user of i915_gem_set_domain() in iris_bufmgr.c
so it was duplicated in i915 backend but a future patch in this series
will take to remove it when the userptr code moves to backend.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23817>
This allow us to remove one more i915_drm.h include from code shared
by both backends.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23905>
This I915_EXEC_FENCE_SIGNAL was missed in the conversion from i915_drm.h
types to IRIS ones.
Both have the same value, so it was not causing any issues.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23905>
This is necessary to initialize context and mark all the state as
dirty so it is re submitted.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24336>
a variable with a component offset may span multiple slots, and this cannot
be inferred from its type alone (e.g., compacted clip+cull distances)
cc: mesa-stable
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24163>
Add support for 1555 and 4444 formats, both in RGB/BGR ordering, with
and without alpha.
These are already supported by Gallium and drivers, but not yet for
winsys surfaces. Adding these is enough to make them renderable when
using Weston on iris.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24331>
Before this patch, when updating the indirect clear color, BLORP only
invalidated the texture cache on gfx11. The hardware docs state that
the texture cache invalidation is also needed on gfx12 however. Add
this invalidation for gfx12 and move the fast-clear related cache
invalidations to the drivers for clarity and performance.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5850
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23588>
We need to set the right value on ReorderMode based on the provoking
vertex mode, or the order in which the vertices for tristrip[_adj] are
delivered to the geometry shader doesn't match what Vulkan expects.
Fixes
dEQP-VK.transform_feedback.primitives_generated_query.concurrent.*triangle_strip_with_adjacency*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23243>
Instead of creating a new context when a reset is encountered, we now
track whether the reset was reported back to the application. According
to the spec, the application should poll the reset status and recreate
the context when NO_ERROR encountered after a RESET.
From the EXT_robustness spec:
5. How should the application react to a reset context event?
RESOLVED: For this extension, the application is expected to query
the reset status until NO_ERROR is returned. If a reset is encountered,
at least one *RESET* status will be returned. Once NO_ERROR is again
encountered, the application can safely destroy the old context and
create a new one.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24224>
Truncate UV coordinates to fix incorrect chroma offset.
Adjust texture offsets to match this change:
0.5 on X
0.25 on Y (interlaced)
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24301>
The number of geometry shader invocations is correctly counted by the
hardware for both NGG and the legacy GS path but it increments for
NGG VS/TES because they are merged with GS, but it shouldn't. Fix this
by emulating the number of geometry shader invocations.
This fixes piglit/bin/arb_query_buffer_object-qbo and recent
dEQP-VK.query_pool.statistics_query.gs_invocations_no_gs.* failures
with NGG.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24231>
In case the case of kmsro and freedreno driver, freedreno will fail to
with the xmlconfig errors as the kmsro declaration doesn't have defaults
for the freedreno options. Instead of directly using v3d_driconf for
kmsro, add native kmsro_driconf, which optionally includes v3d and
freedreno options.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24218>
The kmsro (in theory) can be using any other driver. In order to
simplify handling of driver public headers, move kmsro definition to the
bottom of the drm_helper.h
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24218>
