On Intel HW we use the same mechanism for internal operations surfaces
as well as application surfaces (VkDescriptor).
This change splits the surface pool in 2, one part dedicated to
internal allocations, the other to application VkDescriptors.
To do so, the STATE_BASE_ADDRESS::SurfaceStateBaseAddress points to a
4Gb area, with the following layout :
- 1Gb of binding table pool
- 2Gb of internal surface states
- 1Gb of bindless surface states
That way any entry from the binding table can refer to both internal &
bindless surface states but none of the driver allocations interfere
with the allocation of the application.
Based off a change from Sviatoslav Peleshko.
v2: Allocate image view null surface state from bindless heap (Sviatoslav)
Removed debug stuff (Sviatoslav)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7110
Cc: mesa-stable
Tested-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19275>
(cherry picked from commit 4ceaed7839)
If we're in handle_collect()'s dst allocation and are part of a merge set
near the end of the file, our check for reg_elem_size(reg) would let us
use the preferred reg when that would immediately lead to
allocate_dst_fixed() creating an interval extending thruogh reg_size(reg)
that overflows the file.
Avoids a regression on gfxbench5/gl_5_high_off/17.shader_test in the next
commit. No change on shader-db.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18946>
(cherry picked from commit a39113b616)
While Panfrost allocates linear images with strides that are a multiple of 64
bytes, other dma-buf producers on the system may not satisfy this requirement.
However, at least on v7 and newer, any image with a regular format must have a
stride that is a multiple of 64 bytes.
This fixes a real bug in an application that created a linear R8_UNORM image
with stride 480 bytes, imported it as an EGL_image, and then tried to texture
from it with the GPU. Previously, the driver allowed this situation but it
resulted in an imprecise fault from the GPU. This patch corrects the driver to
reject the import as invalid due to the unaligned stride, ensuring we never
attempt to texture from such a resource.
To implement, we add some new layout queries to centralize knowledge about the
stride alignment requirements, and we sprinkle in asserts to show how the
invariant is upheld throughout the lifecycle of image creation to texturing.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19620>
(cherry picked from commit 811f8a1946)
This can cause us to stomp the contents of r5 before we have a chance to read
it, like this:
0x3d103186bb800000 nop ; nop ; ldvary.r0
0x3d105686bbf40000 nop ; mov rf26, r5 ; ldvary.r1
0x020000ef0000d000 bu.allna 232, r:unif (0x0000001c / 0.000000)
0x3d1096c6bbf40000 nop ; mov rf27, r5 ; ldvary.r2
Here, the MOV in the last instruction is supposed to read r5 produced from
ldvary.r0, but because we have inserted the bu instruction in between now
that read happens at the same time that ldvary.r1 updates r5, stomping the
value we were supposed to read.
Fix this by disallowing injection of a branch instruction in between an ldvary
instruction and its write to the r5 register 2 instructions later.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7062
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19616>
(cherry picked from commit 1174f37609)
The back-end swizzles dwords so that our indirect scratch messages match
the memory layout of spill/fill messages for better cache coherency.
The swizzle happens at a DWORD granularity. If a read or write crosses
a DWORD boundary, the first bit will get correctly swizzled but whatever
piece lands in the next dword will not because the scatter instructions
assume sequential addresses for all bytes. For DWORD writes, this is
handled naturally as part of scalarizing. For smaller writes, we need
to be sure that a single write never escapes a dword.
Fixes: fd04f858b0 ("intel/nir: Don't try to emit vector load_scratch instructions")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7364
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580>
(cherry picked from commit 25c180b509)
Because dup_mem_intrinsic() retains the SSA offset from the original
intrinsic and only modifies it by adding a constant, we can compute the
alignment based on the original alignment and the constant offset. This
is both easier and more accurate.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580>
(cherry picked from commit 85685cf932)
If an application was transitioning out of fullscreen exclusive
display mode, the wsi_display_connector->active state was not
reset in vkReleaseDisplay() from fullscreen. When the app then
later tried to go to fullscreen display mode again on the same
display output with the same video mode, this caused
_wsi_display_queue_next() to skip a required drmModeSetCrtc()
during the first vkQueuePresent() after entering direct display
mode.
While this often worked by pure luck on a single-display setup,
it goes sideways on a multi-display setup where the viewport
of the associated crtc does not have a (x,y) offset of (0,0).
E.g., XOrg/X11 RandR output leasing of an output whose viewport
starts at x = 1920:
1. X-Server has RandR outputs viewport at x = 1920, in a shared
framebuffer, shared across all crtc's on a X-Screen.
2. Application leases that output for direct display mode,
1st vkQueuePresent() triggers drmModeSetCrtc() of output
to (x,y) = 0,0, as required for Vulkan/wsi/direct framebuffer
setup.
3. Application does rendering and presenting.
4. Application vkReleaseDisplay() the output, terminates the
RandR lease. X-Server takes over again.
5. X-Server modesets to reconfigure output back to viewport
with (x,y) = 1920, 0.
6. Application leases same output again later on, and tries
vkQueuePresent() again. Because of the bug fixed in this
commit, the required drmModeSetCrtc() to (x,y) = 0,0 is
erroneously skipped due to the stale cached connector state.
7. drmModePageflip() fails due to the wrong crtc viewport
(x,y) = 1920, 0, mismatched for the need of the Vulkan
framebuffer of (x,y) = 0,0. Kernel returns -ENOSPACE,
Swapchain goes into permanent VK_ERROR_SURFACE_LOST state.
Destroying and recreating the swapchain, as recommended
by the Vulkan spec for error handling won't help. Game over!
Resetting wsi_display_connector->active = false; fixes the
problem of wrong / stale connector state and Vulkan/wsi/display
clients are happy on multi-display setups again, as tested
in various single- and multi-display configurations.
This bug affects all Mesa releases with Vulkan/WSI/Display
support and should therefore be backported.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Fixes: 352d320a07 ("vulkan: Add EXT_direct_mode_display [v2]")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19484>
(cherry picked from commit 24094ee03d)
If the map doesn't set MAP_DISCARD_RANGE, we do have to copy the existing
contents over. MAP_WRITE on its only gives permission to replace the contents,
unfortunately it does not require that the application actually do so.
Closes: #7640
Fixes: 0b26a9f773 ("panfrost: Don't copy resources if replaced")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Roman Elshin
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19576>
(cherry picked from commit cf7a3906b0)
Don't copy propagate the constant in situations like
mov(8) g8<1>D 0x7fffffffD
mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W
On platforms that only have a 32x16 multiplier, this will result in
lowering the multiply to
mul(8) g15<1>D g14<8,8,1>D 0xffffUW
mul(8) g16<1>D g14<8,8,1>D 0x7fffUW
add(8) g15.1<2>UW g15.1<16,8,2>UW g16<16,8,2>UW
On Gfx8 and Gfx9, which have the full 32x32 multiplier, it results in
mul(8) g16<1>D g15<16,8,2>W 0x7fffffffD
Volume 2a of the Skylake PRM says:
When multiplying a DW and any lower precision integer, the
DW operand must on src0.
See also https://gitlab.freedesktop.org/mesa/crucible/-/merge_requests/104.
Previous to INTEL_shader_integer_functions2 (in Vulkan or OpenGL), I
don't think it would be possible to create a situation where this could
occur. I discovered this via some optimizations that can determine that
the non-constant source must be able to fit in 16-bits. The case listed
above came from piglit's "ext_transform_feedback-order arrays points"
with those optimizations in place.
No shader-db or fossil-db changes on any Intel platform.
Fixes: de6c0f8487 ("intel/fs: Implement support for NIR opcodes for INTEL_shader_integer_functions2")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
(cherry picked from commit db20412168)
This patch filters-out '-std=gnu++14' from the cflags obtained
from AOSP/KATI dummy target output to avoid the following building errors:
FAILED: src/gallium/drivers/r600/45f68e3@@r600@sta/sfn_sfn_assembler.cpp.o
...
clang++ ... -std=c++17 ... -std=gnu++14
...
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27:
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32:
In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31:
../src/gallium/drivers/r600/sfn/sfn_instr.h:369:56: error: no template named 'is_base_of_v' in namespace 'std'; did you mean 'is_base_of'?
template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>>
~~~~~^~~~~~~~~~~~
is_base_of
/home/utente/pie-x86_kernel/external/libcxx/include/type_traits:1412:29: note: 'is_base_of' declared here
struct _LIBCPP_TEMPLATE_VIS is_base_of
^
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27:
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32:
In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31:
../src/gallium/drivers/r600/sfn/sfn_instr.h:369:51: error: template argument for non-type template parameter must be an expression
template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/utente/pie-x86_kernel/external/libcxx/include/type_traits:439:16: note: template parameter is declared here
template <bool _Bp, class _Tp = void> using enable_if_t = typename enable_if<_Bp, _Tp>::type;
^
2 errors generated.
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19563>
(cherry picked from commit fd8ec189e5)
XFB queries need to be enabled with NGG streamout and VS/TES.
Previously, the NGG lowering code relied on has_prim_query for XFB.
This fixes failures with RADV_PERFTEST=ngg_streamout on GFX10.3 with
the vkd3d-proton testsuite. Vulkan CTS is missing TES tests with XFB
queries apparently.
Cc: 22.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19493>
(cherry picked from commit 505290dc44)
While the GC880 is HALTI0, it still uses the old set of state registers
for PE pipe configuration. This is another specialty of the GC880, readd
the missing handling for this GPU otherwise e.g. Qt5 cube example suffers
from rendering corruption with both eglfs and wayland backends.
Fixes: 7c46a48836 ("etnaviv: use new PE pipe address states on >= HALTI0")
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19562>
(cherry picked from commit 20984aab0f)
This new section didn't use the correct RST syntax, and ended up
with a broken section in the rendered docs.
Fix the syntax, and clean things up a bit to avoid overly long lines.
Fixes: be235edfe2 ("zink: add profile documentation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19481>
(cherry picked from commit 6b3b633391)
Currently float16 to int64 conversions don't work correctly, because
the "div" variable has an infinite value, since 2^32 isn't
representable as a 16-bit float, which causes the result of of rem(x,
div) to be NaN for all inputs, leading to an incorrect result. Since
no values of magnitude greater than 2^32 are representable as a
float16 we don't actually need to do the fdiv/frem operations, the
conversion is equivalent to f2u32 with the result padded to 64 bits.
Rework:
* Jordan: Handle f16 in if/else rather than conditional
Fixes: 936c58c8fc ("nir: Extend nir_lower_int64() to support i2f/f2i lowering")
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19391>
(cherry picked from commit e14f85366e)
