Because these files indeed doesn't belongs to src/util, they are tightly coupled with
src/gallium/auxiliary
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19522>
As u_pack_color.h is used in vulkan drivers, so decouple it from gallium by this move
And dbghelp.h is included in u_debug_symbol.c and that's resident in src/util/
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19522>
As pipe_color_union is used in vulkan drivers, so decouple it from gallium by this move
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19522>
PIPE_MASK_* is used by src/util/*, so do the move to decouple src/util/* from gallium
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19522>
pipe_swizzle is used by src/util/*, so do the move to decouple src/util/* from gallium
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19522>
base feedback loop ext is more like a hard requirement, but it's tough to
pin down exactly which version requires it, and also it might "just work"
magically, so...yeah here we are
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24403>
sed + ninja clang-format + fix up spacing for common code.
If you are unhappy that I did not manually change the whitespace of your driver,
you need to enable clang-format for it so the formatting would happen
automatically.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24428>
Not used on Midgard, deals with a -Wunused-function warning.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Italo Nicola <italonicola@collabora.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24428>
On platforms with an indirect clear color BO, the clear color used when
sampling is in the form of a pixel. The sampler can interpret the pixel
correctly regardless of the format, so allow fast clears in more cases
within iris_resource_prepare_texture.
On gfx12, this completely removes partial resolves in a couple game
traces I tested:
- 72 partial resolves in a 500 frame trace of CS:GO.
- 1207 partial resolves in a 500 frame trace of Dota 2.
The resolves were triggered when ISL_FORMAT_A8_UNORM surfaces were
sampled as ISL_FORMAT_R8_UNORM.
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24323>
Preferring interlaced results in all surfaces being allocated
as interlaced for H264 decode regardless of whether the decoded
pic is interlaced or progressive, which makes VA postproc
apply deinterlacing even for progressive pics.
Deinterlacing interlaced pics still works because VA frontend
will now reallocate surface as interlaced when decoding interlaced
pics.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
When decoding interlaced pics, the output surface should
also be allocated as interlaced to make the deinterlace
postproc filter work correctly.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
When decoding interlaced pics, the output surface should
also be allocated as interlaced to make the deinterlace
postproc filter work correctly.
This makes deinterlacing work for drivers that supports, but
not prefers, interlaced surfaces.
Use extra buffer instead of reallocating as non-interlaced
when exporting interlaced surfaces.
v2: Avoid reallocating in vlVaExportSurfaceHandle
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24361>
MOCS = 0 is a invalid MOCS index on MTL, so it is necessary get a
valid value and set to MI_MATH instructions.
So here the mocs index is set with mi_builder_set_mocs(), it can be
always set but it is required when mi_build will emit MI_MATH
instructions.
The mocs index will only be stored and used in gfx12.5+ platforms
so no changes were are required in crocus or hasvk.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22508>
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>
