- 10 Dec, 2022 3 commits
-
-
Dylan Baker authored
-
Dylan Baker authored
-
Dylan Baker authored
-
- 30 Nov, 2022 6 commits
-
-
This allows to build libgbm when system = 'android' is set in the cross_file. Cc: "22.3" "22.2" mesa-stable Signed-off-by:
Roman Stratiienko <r.stratiienko@gmail.com> Acked-by:
Mauro Rossi <issor.oruam@gmail.com>
Part-of: <!20033>
(cherry picked from commit 09ac29cc) -
Starting with !19748 lowered 64 bit shifts were showing wrong results for shifts with insignificant bits set. nir shifts are defined to only look at the least significant bits. The lowering has take this into account. So there are two things going on: 1. the `ieq` and `uge` further down depend on `y` being masked. 2. the calculation of `reverse_count` actually depends on a masked `y` as well, due to the `(iabs (iadd y -32))` giving a different result for shifts > 31; Fixes: 41f3e9e5 ("nir: Implement lowering of 64-bit shift operations") Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: 
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <!19995> (cherry picked from commit 5398dd04)
-
video corruption observed while running decode test for av1 content in chromeos. solution is when target buffer is found in render pic list and when target codec is null, set curr_pic_indx as index to the pic in render pic list. Cc: mesa-stable Signed-off-by:
Sajeesh Sidharthan <sajeesh.sidharthan@amd.com> Reviewed-by:
Boyuan Zhang <Boyuan.Zhang@amd.com> Part-of: <!20000> (cherry picked from commit 8b99e96d)
-
Using a designated initializer like this leaves padding bits, which form part of the aliasing u64/f64 member of the union, uninitialised, but a nir_const_value must always have the unused bits zeroed out. Thus, use the nir_const_value_for_float helper instead like everywhere else which will do a memset 0 for us first. Without this, using the pan_blend shader in a build with validation enabled fails with: NIR validation failed after nir_lower_vars_to_ssa ... vec4 32 ssa_58 = load_const (0x3f7cfcfd /* 0.988235 */, 0x3f7cfcfd /* 0.988235 */, 0x3f7cfcfd /* 0.988235 */, 0x3f800000 /* 1.000000 */) error: memcmp(val, &cmp_val, sizeof(cmp_val)) == 0 (../src/compiler/nir/nir_validate.c:976) Fixes: 1378c67b ("panfrost/blend: Inline blend constants") Part-of: <!20071> (cherry picked from commit 75032573) -
It's not in the key, so it randomly may or may not be present, and if it is present then we don't actually save/restore the contents, so we will save/restore random pointer values from the last run. Turnip already disables searching the shader cache when assembly is requested, but still wrote the final ir3_shader_variant which resulted in trying to save random stale pointers when saving off the executable if a subsequent compile hit that cache entry. This fixes flakes in dEQP-VK.pipeline.pipeline_library.shader_module_identifier.pipeline_from_id.* for me. Fixes: 56909868 ("turnip: implement VK_KHR_pipeline_executable_properties") Part-of: <!20056> (cherry picked from commit 8ba2d612)
-
Dylan Baker authored
-
- 29 Nov, 2022 1 commit
-
-
Christopher Egert authored
The cherry pick 3ae1f012 adds max_uniform_block_size to the virgl_caps_v2 struct without the video_caps, so max_uniform_block_size contains the wrong data which regresses OpenGL 4.3 down to 3.0. Part-of: <!20065>
-
- 28 Nov, 2022 21 commits
-
-
Clearing ts_size - ts_offset bytes in a level means we are clearing the TS region of all layers in the level starting from the surface layer, so clearing one surface might corrupt all other layers of a resource level. Use the correct size to clear only the requested TS region. Cc: mesa-stable Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Part-of: <!19814> (cherry picked from commit b6fa3cdb)
-
Using the ts_offset from the level means we are always clearing the TS region of layer 0 of the level. Use the correct offset which takes into account the layer offset. Cc: mesa-stable Signed-off-by:
-
Source engine uses flawed device detection in Linux native OpenGL backend, which causes it to use bad configurations for Intel devices and thus not always render correctly. Workaround this by using vendor string that does not include "Intel" in it. Cc: mesa-stable Closes: #7725 Signed-off-by:
Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <!19828>
(cherry picked from commit 478ffe71) -
-
-
-
NIR shifts are defined to truncate the shift amount to the number of bits needed to represent the bit-size of the value shifted. LLVM treats large shifts as poison. This fix achieves NIR semantics for shifts. As an example, a|(b << 32), where "a" is 32bits, should produce a|b according to NIR (because 32&31 == 0). This caused LLVM to incorrectly optimize "(a >> c) | (b << (32 - c))" to a u2u32(pack_64_2x32(a, b) >> c) (v_alignbit_b32), when the original NIR should have returned "a | b" if c==0. Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Mihai Preda <mhpreda@gmail.com> Reviewed-by:
Qiang Yu <yuq825@gmail.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Cc: mesa-stable Part-of: <!19966> (cherry picked from commit 064336d3)
-
It's legal in OpenGL to start a query even if the result will have zero valid bits. It's not enough to just report zero bits, We need to also prevent calling down into the driver with these invalid queries. Because ARB_ES3_compatibility adds ANY_SAMPLES_PASSED and ANY_SAMPLES_PASSED_CONSERVATIVE to the set of queries that support zero bits, we also need to check for the corresponding indices. Fixes: 0186e9e1 ("mesa: always support occlusion queries") Reviewed-by:
Soroush Kashani <soroush.kashani@imgtec.com> Reviewed-by:
-
-
-
We can go up to 15 instructions out of order (performance fix) but we can't go past a branch (bug fix). Fixes: 30a393f4 ("pan/mdg: Enable out-of-order execution after texture ops") Signed-off-by:
Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <!19762>
(cherry picked from commit 04442821) -
They are u64. Fixes deadlock in dEQP-VK.wsi.xcb.present_id_wait.wait.past_no_timeout. Signed-off-by:
Hans-Kristian Arntzen <post@arntzen-software.no> Fixes: 9bffd81f ("vulkan: Add common implementations of vkQueueSubmit and vkQueueWaitIdle") Reviewed-by:
Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: 
Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <!19951>
(cherry picked from commit f2e535e4) -
Similar to anv_address Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9c1c1888
("intel/fs: put scratch surface in the surface state heap")
Reviewed-by: 
Ivan Briano <ivan.briano@intel.com>
Part-of: <!19946>
(cherry picked from commit 20e8e1eb) -
The initial implementation is a pretty big hammer. Implement the HW recommendation to minimize cases in which we need a fence. This improves by 10FPS on some of the Sascha Willems RT demos. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 6031ad4b
("intel/fs: Add Wa_22013689345")
Reviewed-by: Francisco Jerez <currojerez@riseup.net> Part-of: <!19322> (cherry picked from commit 94563751)
-
Dylan Baker authored
-
This might fix some window system issues. Fixes: 3da170fa - glthread: change when glFlush flushes asynchronously Acked-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19809> (cherry picked from commit d8719587)
-
This fixes a longstanding bug in the interaction between TS and a write mapping. The write does not update TS regardless of the way the update is done. Update via etna_copy_resource would just set the target ts_valid to false without actually writing back any dirty TS to the resource. Writes via the CPU would update the resource, but keep ts_valid at true even if the tile status may now not match the actually written tiles of the resource anymore. Fix this by writing back a dirty TS to the target resource if needed before updating the level with the write data. Always invalidate TS, even when the update is done by the CPU. Cc: mesa-stable Signed-off-by:
-
There seems to be a problem with running firefox by using Xwayland that results in a shared resources being not always tagged as using staging. As a result one process tries to map the resource that was allocated as one that uses staging without actually using the staging resource, and hence the mapped range only accounts for the small region that we have to allocated because a zero-allocation doesn't work, but the application mapping the resource assumes that a properly sized range is mapped, and consequently this results in invalid memory access. To work around this issue disable creating staging for resources that are created by using shared binding. It is not clear to me whether this is the best fix, but it seems to quell the issue. Fixes: c9d99b7e virgl: Fix texture transfers by using a staging resource Related: virgl/virglrenderer#291 Part-of: <!19655> (cherry picked from commit e496d24c)
-
This reverts commit 811f8a19. As Alpine put it -- this is causing more problems than it's fixing. Hotfix to revert the offending commit until a more measured fix can be implemented. Closes: #7731 Cc: mesa-stable Signed-off-by:
Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Jan Palus
Part-of: <!19993>
(cherry picked from commit 4b19725e) -
Dylan Baker authored
-
Dylan Baker authored
-
- 24 Nov, 2022 2 commits
-
-
Cc: mesa-stable Signed-off-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <!19825>
-
Otherwise github actions would show a bit confusing Signed-off-by:
-
- 22 Nov, 2022 1 commit
-
-
maurossi authoredThis is backport of mesa 23.0 commit e74d989a with resolution of conflicts for mesa 22.2 branch static constexpr const 'value' is replaced by static function in all type_char template specializations to avoid the following building errors happening with clang 6 /home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::ExportInstr>::value >>> referenced by sfn_scheduler.cpp >>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::ExportInstr>(std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&, std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a ... /home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::RatInstr>::value >>> referenced by sfn_scheduler.cpp >>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::RatInstr>(std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&, std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) Cc: "22.2" "22.3" mesa-stable Reviewed-by:
Gert Wollny <gert.wollny@collabora.com> Part-of: <!19940>
-
- 21 Nov, 2022 6 commits
-
-
-
Found when 16bit vec3 varying with llvm14 (not found when llvm15), one 32bit vec4 slot is filled like this: vec3[0] | undef vec3[1] | undef vec3[2] | undef undef | undef LLVM error is for the elements with undef: %287 = insertelement float %280, half %279, i64 0 After this change, we get: %287 = insertelement <2 x half> %280, half %279, i64 0 Fixes: 279eea5b ("amd/llvm: Transition to LLVM "opaque pointers"") Reviewed-by:
-
Moving entire chunks of code into a dummy if block is causing issues in some situations. To work around the issue that we tried to fix in 35d82ecf ("nir/lower_shader_calls: put inserted instructions into a dummy block") which is that we cannot cut and past a block of instruction that ends with a jump if there are more instruction behind where we're going to past. We can instead just wraps the jumps into dummy if blocks. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com> Part-of: <!19820> (cherry picked from commit 3686d5a3)
-
Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: -
Fixes: c2a81ebe ("nir: Add default unsigned upper bound configuration.") Closes: #7676 Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <!19835>
(cherry picked from commit 2ba55ec5) -
This pass can insert if blocks, therefore no dominance/block_index for you. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by:
-
