- Nov 09, 2022
-
-
Eric Engestrom authored
-
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: mesa/mesa#7062 Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> cc: mesa-stable Part-of: <mesa/mesa!19616> (cherry picked from commit 1174f376)
-
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: fd04f858 ("intel/nir: Don't try to emit vector load_scratch instructions") Closes: mesa/mesa#7364 Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <mesa/mesa!19580> (cherry picked from commit 25c180b5)
-
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: <mesa/mesa!19580> (cherry picked from commit 85685cf9)
-
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: 352d320a ("vulkan: Add EXT_direct_mode_display [v2]") Cc: mesa-stable Part-of: <mesa/mesa!19484> (cherry picked from commit 24094ee0)
-
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: 0b26a9f7 ("panfrost: Don't copy resources if replaced") Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Reported-by: Roman Elshin Part-of: <mesa/mesa!19576> (cherry picked from commit cf7a3906)
-
Sync UAPI for the upstream fix. Upstream commit: https://cgit.freedesktop.org/drm-misc/commit/?h=drm-misc-fixes&id=c4299907c09a638c0a30f029338d07941c049d73 Closes: #7195 Fixes: 6a4532cb ("panfrost: Sync panfrost_drm.h from drm-misc-next") Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Tested-by: Chris Healy <healych@amazon.com> Part-of: <mesa/mesa!19581> (cherry picked from commit d40af879)
-
Stick to macos-11 to prevent accident broken always install meson with pip to prevent pull new version of python Cc: mesa-stable Signed-off-by: Yonggang Luo <luoyonggang@gmail.com> Acked-by: Eric Engestrom <eric@igalia.com> Part-of: <mesa/mesa!19615> (cherry picked from commit 81b4af28)
-
Fixes issue with "is helper invocation" that in recent SPIR-V is mapped to a volatile Load. The CSE was catching the loads before they were transformed in the new is_helper_invocation intrinsic (that is not reorderable). Fixes: 729df14e ("nir: Handle volatile semantics for loading HelperInvocation builtin") Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: M Henning <drawoc@darkrefraction.com> Part-of: <mesa/mesa!19432> (cherry picked from commit 8ab628ab)
-
Fixes: 13c422e1 ("anv: toggle on EXT_extended_dynamic_state3") Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Part-of: <mesa/mesa!19573> (cherry picked from commit 97b3dd34)
-
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 mesa/crucible!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: de6c0f84 ("intel/fs: Implement support for NIR opcodes for INTEL_shader_integer_functions2") Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <mesa/mesa!17718> (cherry picked from commit db204121)
-
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: <mesa/mesa!19563> (cherry picked from commit fd8ec189)
-
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: <mesa/mesa!19493> (cherry picked from commit 505290dc)
-
Meta operations change dynamic states like viewports and previously, the guardband state was also always re-emitted because it relied on dynamic viewport/scissor changes. Closes: mesa/mesa#7577 Fixes: 40d8df72 ("radv: emit the guardband state separately from the scissor state") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19521> (cherry picked from commit 33d60bda)
-
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: 7c46a488 ("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: <mesa/mesa!19562> (cherry picked from commit 20984aab)
-
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: be235edf ("zink: add profile documentation") Part-of: <mesa/mesa!19481> (cherry picked from commit 6b3b6333)
-
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: 936c58c8 ("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: <mesa/mesa!19391> (cherry picked from commit e14f8536)
-
Fixes: ba02ed91 - ac/gfx11: fix the scratch buffer Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <mesa/mesa!19477> (cherry picked from commit bdfacd0a)
-
Closes: #6348 cc: mesa-stable Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19534> (cherry picked from commit e5b3efe5)
-
`pred` is a pointer, for sufficiently large numbers these being cast to int were both > 0 regardless of the order of `data1` and `data2`. Fixes: 523a28d3 ("nir: add an instruction set API") Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com> Part-of: <mesa/mesa!19539> (cherry picked from commit c987a727)
-
It seems INV_L2 is the right thing to do, especially for RDNA2 chips with non-coherent RBs (NAVI22 is one of these). This fixes DCC corruption. Closes: mesa/mesa#6476 Closes: mesa/mesa#7507 Cc: mesa-stable Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19516> (cherry picked from commit 06adf6ad)
-
GDS is used for NGG queries/streamout (GFX10+ only) and the BOs were only added to the graphics queue because compute doesn't need them. Though, the kernel emits a GDS switch when a queue submission doesn't use GDS. That means that submitting jobs on the compute queue without GDS can reset the state of the graphics queue and lead to GPU hangs. The only viable solution for now is to make the GDS BOs resident to avoid resetting the state between queues. This shouldn't introduce more syncs between queues because GDS BOs are similar for both. This fixes a GPU hang with Warhammer Chaosbane during loading time and possibly some spurious random GPU hangs. Note that this GPU hang was workarounded on the Steam side with RADV_DEBUG=nongg. Cc: mesa-stable Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19466> (cherry picked from commit 26c8fedc)
-
This test as a whole does not seem to work anywhere, even lavapipe, but one particular subtest was passing until a recent change (!19438 - zink: polygon mode fixes?). After consideration by @kusma, it appears that the subtest was passing by accident due to zink generating the wrong values. Given that this is not something that users would ever experience as a regression, we simply document this new failure along with all the others for this test. Fixes: 53721827 ("zink: correct depth-bias enable condition") Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org> Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <mesa/mesa!19517> (cherry picked from commit d7ad9e70)
-
Fixes: e6884df0 ('v3dv: fix event synchronization') Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Part-of: <mesa/mesa!19518> (cherry picked from commit 22789d34)
-
We have been incorrectly assuming there was just one for all the events, apparently CTS never uses more than one event. Fixes: e6884df0 ('v3dv: fix event synchronization') Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Part-of: <mesa/mesa!19518> (cherry picked from commit 36ef75b6)
-
Just like on Lavapipe, Emma Anholt's !19124 also fixed the restore-sso-program test on RADV. Fixes: 4e14da05 ("zink: Enable mesa/st frontend shader caching.") Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org> Part-of: <mesa/mesa!19468> (cherry picked from commit dc088754)
-
Found by inspection because the MIN_LOD bits were moved. Cc: 22.3 mesa-stable Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19496> (cherry picked from commit e891e84f)
-
anv_device.c for vulkan.intel_hasvk requires changes to be compiled and behave correctly for android target Fixes the following building error: FAILED: src/intel/vulkan_hasvk/libanv_hasvk_common.a.p/anv_device.c.o ... ../src/intel/vulkan_hasvk/anv_device.c:143:19: error: use of undeclared identifier 'ANV_API_VERSION_1_3' *pApiVersion = ANV_API_VERSION_1_3; ^ ../src/intel/vulkan_hasvk/anv_device.c:1822:44: error: use of undeclared identifier 'ANV_API_VERSION_1_3' .apiVersion = pdevice->use_softpin ? ANV_API_VERSION_1_3 : ANV_API_VERSION_1_2, ^ ../src/intel/vulkan_hasvk/anv_device.c:1822:66: error: use of undeclared identifier 'ANV_API_VERSION_1_2' .apiVersion = pdevice->use_softpin ? ANV_API_VERSION_1_3 : ANV_API_VERSION_1_2, ^ 3 errors generated. Cc: "22.3" mesa-stable Fixes: 00eefdcd ("hasvk: stop advertising Vk 1.3 on non-softpin") Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Part-of: <mesa/mesa!19452> (cherry picked from commit 814b822f)
-
Ubuntu 20.04 ships a glslangValidator that doesn't know about vulkan1.2 yet. Fixes: 27186537 ("radv: Add PLOC shader") Part-of: <mesa/mesa!19479> (cherry picked from commit 95ed0330)
-
Noticed by inspection after the previous issue. Fixes: 68f3c38c ("tu: Implement extendedDynamicState2PatchControlPoints") Part-of: <mesa/mesa!18912> (cherry picked from commit 4466f9aa)
-
Since we now implement events in the GPU we need to be more careful and insert barriers to honor the dependencies provided by the API as well as ensuring we are synchronizing these with the compute queue, since that is how we implement GPU event functionality. Fixes: ecb01d53 ("v3dv: refactor events") Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Part-of: <mesa/mesa!19458> (cherry picked from commit e6884df0)
-
Fixes: ecb01d53 ("v3dv: refactor events") Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> Part-of: <mesa/mesa!19458> (cherry picked from commit 8113f973)
-
Fixes: a981ac05 ('v3dv: skip binning sync if binning shaders don't access external resources') Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> Part-of: <mesa/mesa!19458> (cherry picked from commit 67e82fd1)
-
Fixes: ecb01d53 ("v3dv: refactor events") Fixes: dEQP-VK.api.command_buffers.execute_large_primary Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> Part-of: <mesa/mesa!19458> (cherry picked from commit 4c861cf2)
-
Fixes (with disk cache enabled): dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic dEQP-VK.api.object_management.alloc_callback_fail.device dEQP-VK.api.object_management.alloc_callback_fail.device_group Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> cc: mesa-stable Part-of: <mesa/mesa!19458> (cherry picked from commit 5e97150e)
-
Fixes (with disk cache disabled): dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic dEQP-VK.api.object_management.alloc_callback_fail.device dEQP-VK.api.object_management.alloc_callback_fail.device_group Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> cc: mesa-stable Part-of: <mesa/mesa!19458> (cherry picked from commit 1f596639)
-
Fixes: ecb01d53 ("v3dv: refactor events") Partially fixes: dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic dEQP-VK.api.object_management.alloc_callback_fail.device dEQP-VK.api.object_management.alloc_callback_fail.device_group Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> Part-of: <mesa/mesa!19458> (cherry picked from commit 7f905a81)
-
These leaks on device creation failure have been there before, but were only exposed as CTS failures after the recent event refactoring. Partially fixes: dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic dEQP-VK.api.object_management.alloc_callback_fail.device dEQP-VK.api.object_management.alloc_callback_fail.device_group Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> cc: mesa-stable Part-of: <mesa/mesa!19458> (cherry picked from commit b78fd50e)
-
Fixes: ecb01d53 ("v3dv: refactor events") Signed-off-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Part-of: <mesa/mesa!19458> (cherry picked from commit aff368fe)
-
We are initializing the device, so we know this will be NULL. Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> Reviewed-by: Eric Engestrom <eric@igalia.com> cc: mesa-stable Part-of: <mesa/mesa!19458> (cherry picked from commit c793d384)
-