- 21 Aug, 2020 1 commit
-
-
Sebastian Krzyszkowiak authored
-
- 20 Aug, 2020 1 commit
-
-
Sebastian Krzyszkowiak authored
-
- 19 Aug, 2020 1 commit
-
-
Sebastian Krzyszkowiak authored
-
- 15 Aug, 2020 4 commits
-
-
Sebastian Krzyszkowiak authored
Update mesa to 20.1.5 Closes #1 See merge request Librem5/mesa!3
-
Sebastian Krzyszkowiak authored
-
Sebastian Krzyszkowiak authored
-
Sebastian Krzyszkowiak authored
-
- 13 Aug, 2020 2 commits
-
-
Sebastian Krzyszkowiak authored
This fixes hangs with some GL applications.
-
Sebastian Krzyszkowiak authored
-
- 12 Aug, 2020 2 commits
-
-
Sebastian Krzyszkowiak authored
Tagging upload of mesa 20.1.5-1 to unstable.
-
Sebastian Krzyszkowiak authored
-
- 10 Aug, 2020 3 commits
-
-
Timo Aaltonen authored
-
Timo Aaltonen authored
-
Timo Aaltonen authored
-
- 05 Aug, 2020 26 commits
-
-
Eric Engestrom authored
-
Eric Engestrom authored
-
Marek Olšák authored
Fixes: 9680a754 "radeonsi/gfx9: enable SDMA buffer copying & clearing" Acked-by:
Marek Olšák <marek.olsak@amd.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4895> (cherry picked from commit 07a49bf5)
-
Kristian H. Kristensen authored
Otherwise it doesn't compile. Reviewed-by:
Eric Engestrom <eric@engestrom.ch> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: aba57b11 ("anv: support GetSwapchainGrallocUsage2ANDROID for Android") Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6112> (cherry picked from commit ff0dbf20)
-
Jason Ekstrand authored
One day, we may want copy_prop_vars or other passes to be able to see through certain types of casts such as when someone casts a uint64_t to a uvec2. However, for now we should just avoid casts all together. Fixes: d8e3edb7 "nir/deref: Support casts and ptr_as_array in..." Tested-by:
Jesse Natalie <jenatali@microsoft.com> Reviewed-by:
Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6072> (cherry picked from commit 611f654f)
-
Jason Ekstrand authored
We don't care about full IA coherency since we always have the opportunity in GL or Vulkan to flush the data cache. Using IA-coherent mode is likely just making A64 access slower than it needs to be. Reviewed-by:
Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4819> (cherry picked from commit 4985e380)
-
Alyssa Rosenzweig authored
It's possible an SSA value depends on a register; in this case, chasing the source would result in a crash as the chase helper in NIR asserts is_ssa. Instead we should check a priori that all the argments are in fact SSA, bailing otherwise. In the piglit shader exhibiting this bug (by looping over the index), bailing on the ishl instruction is -necessary-. This is not merely us being cowardly to avoid seeing through the registers; indeed, if we wrote away the ishl instruction, the shift itself would have to be stored in a load/store register (r26/r27) which would preclude reading it in the loop, creating a register allocation failure later in the compile. So this is the correct solution due to the restricted semantics. Closes #3286 Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reported-by:
Icecream95 <ixn@keemail.me> Fixes: f5401cb8 ("pan/midgard: Add address analysis framework") Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6144> (cherry picked from commit b2f47525)
-
Alyssa Rosenzweig authored
This prevents RA failures the results of reading multiple textures that require less than 4 channels, as seen in a number of GL 3 WebRender shaders. Closes: #3342 Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reported-by:
Icecream95 <ixn@keemail.me> Tested-by:
Icecream95 <ixn@keemail.me> Cc: mesa-stable Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6144> (cherry picked from commit b4de9e03)
-
Bas Nieuwenhuizen authored
_mesa_delete_memory_object(ctx, obj) == free(obj) but doesn't free the part of the gallium driver. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1206 Fixes: 49f4ecc6 "mesa/st: start adding memory object support" Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6148> (cherry picked from commit 99cf9108)
-
Mauro Rossi authored
Fixes the following building error: external/mesa/src/amd/vulkan/radv_android.c:28:10: fatal error: 'vndk/hardware_buffer.h' file not found ^~~~~~~~~~~~~~~~~~~~~~~~ (v2) use the existing preprocessor condition #if ANDROID_API_LEVEL >= 26 Fixes: f36b5274 "radv/android: Add android hardware buffer queries." Reported-and-tested-by:
youling 257 <youling257@gmail.com> Signed-off-by:
Mauro Rossi <issor.oruam@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6051> (cherry picked from commit 80c135e6)
-
Marcin Ślusarz authored
NIR_MAX_VEC_COMPONENTS was bumped from 4 to 16 in a8ec4082 (2019.03.09, merged 2019.12.21) float[4] array was added in acd7796a (2019.06.11, merged 2019.07.11) Found by Coverity. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3014Signed-off-by:
Marcin Ślusarz <marcin.slusarz@intel.com> Fixes: a8ec4082 ("nir+vtn: vec8+vec16 support") Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6067> (cherry picked from commit cb19fe24)
-
Marcin Ślusarz authored
ColorDrawBuffer is an array of MAX_DRAW_BUFFERS == 8. Found by Coverity. Signed-off-by:
Marcin Ślusarz <marcin.slusarz@intel.com> Fixes: 7534c536 ("mesa: add EXT_dsa (Named)Framebuffer functions") Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6067> (cherry picked from commit 0906d5d5)
-
Marcin Ślusarz authored
Found by Coverity. Signed-off-by:
Marcin Ślusarz <marcin.slusarz@intel.com> Fixes: f8f14130 ("util/u_process: add util_get_process_exec_path") Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6067> (cherry picked from commit f13042ec)
-
Marcin Ślusarz authored
Found by Coverity. Signed-off-by:
Marcin Ślusarz <marcin.slusarz@intel.com> Fixes: ef5266eb ("util/os_socket: Add socket related functions.") Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6067> (cherry picked from commit eac0ba7f)
-
Frank Binns authored
This effectively reverts part of 2907faee, which changed dri2_make_current() to always take a dri2_dpy reference regardless of whether or not a new context or surface(s) were being bound. This led to a reference count imbalance as there was no corresponding code added to drop a reference on the dri2_dpy. As a consequence, any application that called eglInitialize() on a default/native display after having called eglTerminate() would always get back the old dri2_dpy, inheriting its previous state. As the reference count is there to prevent the dri2_dpy from being destroyed between eglTerminate() and eglInitialize() calls when a context is still bound, a reference should only be taken when a successful call to dri2_dpy->core->bindContext() has been made. Fix the issue by restoring the old reference counting behaviour. Fixes: 4e8f95f6 ("egl_dri2: Always unbind old contexts") Fixes: 2907faee ("egl/dri2: try to bind old context if bindContext failed") Signed-off-by:
Frank Binns <frank.binns@imgtec.com> Reviewed-by:
Luigi Santivetti <luigi.santivetti@imgtec.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Tested-by:
Nicolas Cortes <nicolas.g.cortes@intel.com> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3328 Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6105> (cherry picked from commit d0e32e5f)
-
Kenneth Graunke authored
We were space-leaking iris_compiled_shader objects, leaving them around basically forever - long after the associated iris_uncompiled_shader was deleted. Perhaps even more importantly, this left the BO containing the assembly referenced, meaning those were never reclaimed either. For long running applications, this can leak quite a bit of memory. Now, when freeing iris_uncompiled_shader, we hunt down any associated iris_compiled_shader objects and pitch those (and their BO) as well. One issue is that the shader variants can still be bound, because we haven't done a draw that updates the compiled shaders yet. This can cause issues because state changes want to look at the old program to know what to flag dirty. It's a bit tricky to get right, so instead we defer variant deletion until the shaders are properly unbound, by stashing them on a "dead" list and tidying that each time we try and delete some shader variants. This ensures long running programs delete their shaders eventually. Fixes: ed4ffb97 ("iris: rework program cache interface") Reviewed-by:
Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6075> (cherry picked from commit 128cbcd3)
-
Daryl W. Grunau authored
Without this patch applied gcc@10.1.0 fails to compile with the following error (note mesa@18.3.6 but the latest release also posseses this problem): ld: ../../../../src/gallium/auxiliary/.libs/libgallium.a(u_debug_symbol.o):/tmp/spack/spack-stage/spack-stage-mesa-18.3.6-be7kyg2dyxwktir3zrai27n6a6coadab/spack-src/src/galli um/auxiliary/util/u_debug_symbol.c:273: multiple definition of `symbols_hash'; ../../../../src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o):/tmp/spa ck/spack-stage/spack-stage-mesa-18.3.6-be7kyg2dyxwktir3zrai27n6a6coadab/spack-src/src/gallium/auxiliary/util/u_debug_stack.c:49: first defined here collect2: error: ld returned 1 exit status make[4]: *** [libGL.la] Error 1 make[4]: Leaving directory `/tmp/spack/spack-stage/spack-stage-mesa-18.3.6-be7kyg2dyxwktir3zrai27n6a6coadab/spack-src/src/gallium/targets/libgl-xlib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/tmp/spack/spack-stage/spack-stage-mesa-18.3.6-be7kyg2dyxwktir3zrai27n6a6coadab/spack-src/src/gallium' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/spack/spack-stage/spack-stage-mesa-18.3.6-be7kyg2dyxwktir3zrai27n6a6coadab/spack-src/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/spack/spack-stage/spack-stage-mesa-18.3.6-be7kyg2dyxwktir3zrai27n6a6coadab/spack-src/src' make: *** [all-recursive] Error 1 Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3298 Cc: mesa-stable Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Reviewed-by:
Eric Engestrom <eric@engestrom.ch> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6053> (cherry picked from commit a400c2ff)
-
Lionel Landwerlin authored
Once we start going through the free list of the descriptor set pool, we might use a free entry larger than the descriptor set we want to allocate. When we free that descriptor set, we use the size of the set rather than the size of the entry that was picked. This leads to leaks of some amount of descriptor set pool. This fix saves the size of the entry in the descriptor set so we know what amount of the pool needs to freed. v2: Don't bother adding a new size field Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Danylo Piliaiev <danylo.piliaiev@globallogic.com> Cc: <mesa-stable@lists.freedesktop.org> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3324 Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6084> (cherry picked from commit 1cdd161a)
-
Yevhenii Kolesnikov authored
Volume textures don't have a concept of "layers" v1: set last_layer to zero for 3D textures (Axel Davy) Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by:
Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com> Reviewed-by:
Axel Davy <davyaxel0@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5808> (cherry picked from commit 845a50ee)
-
Marcin Ślusarz authored
Otherwise mesa will crash in glEndPerfQueryINTEL because OA BO is NULL. Signed-off-by:
Marcin Ślusarz <marcin.slusarz@intel.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6094> (cherry picked from commit 88471831)
-
Marcin Ślusarz authored
Otherwise mesa will crash in glEndPerfQueryINTEL because OA BO is NULL. Signed-off-by:
Marcin Ślusarz <marcin.slusarz@intel.com> Cc: <mesa-stable@lists.freedesktop.org> Reviewed-by:
Mark Janes <mark.a.janes@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6094> (cherry picked from commit 627c0197)
-
Bas Nieuwenhuizen authored
Fixes: 88d41367 "radv: Add timelines with a VK_KHR_timeline_semaphore impl." Reviewed-by:
Dave Airlie <airlied@redhat.com> Tested-by:
Andres Rodriguez <andresx7@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6097> (cherry picked from commit 05b27832)
-
Bas Nieuwenhuizen authored
Fixes some dEQP-VK.renderpass2.* flakes. Valgrind: Test case 'dEQP-VK.renderpass2.dedicated_allocation.attachment.8.724'.. ==754520== Conditional jump or move depends on uninitialised value(s) ==754520== at 0x575B21C: radv_layout_is_htile_compressed (radv_image.c:1690) ==754520== by 0x572F470: radv_handle_depth_image_transition (radv_cmd_buffer.c:5855) ==754520== by 0x572F2F2: radv_handle_image_transition (radv_cmd_buffer.c:6123) ==754520== by 0x572EEC6: radv_handle_subpass_image_transition (radv_cmd_buffer.c:3385) ==754520== by 0x572A104: radv_cmd_buffer_begin_subpass (radv_cmd_buffer.c:4843) ==754520== by 0x572A007: radv_CmdBeginRenderPass (radv_cmd_buffer.c:4913) ==754520== by 0x572A197: radv_CmdBeginRenderPass2 (radv_cmd_buffer.c:4921) Why false? A renderloop happens when the same attachment is both used as input attachment and output (color, ds) attachment in a subpass. Of course this doesn't happen outside of a renderpass and hence we can initialize it to false at the start of the renderpass. Fixes: 66131ceb "radv: Pass through render loop detection to internal layout decisions." Reviewed-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Daniel Schürmann <daniel@schuermann.dev> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3074 Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6068> (cherry picked from commit 18fe130e)
-
Daniel Schürmann authored
Cc: 20.1 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6024> (cherry picked from commit 4c89bfc4)
-
Daniel Schürmann authored
Cc: 20.1 <mesa-stable@lists.freedesktop.org> Reviewed-by:
Rhys Perry <pendingchaos02@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6024> (cherry picked from commit 626081fe)
-
Francisco Jerez authored
This avoids some performance regressions on Gen12 platforms caused by SIMD32 fragment shaders reported in titles like Dota2, TF2, Xonotic, and GFXBench5 Car Chase and Aztec Ruins. The most obvious pattern in the regressing shaders I identified among these workloads is that they all had non-uniform discard statements, which are handled rather optimistically by the current IR analysis pass: No penalty is currently applied to the SIMD32 variant of the shader in the form of differing branching weights like we do for other control flow instructions in order to account for the greater likelihood of divergence of a SIMD32 shader. Simply changing that by giving the same treatment to discard statements as we give to other branching instructions seemed to hurt more than it helped on platforms earlier than Gen12, since it reversed most of the improvement obtained from SIMD32 fragment shaders in Manhattan for no measurable benefit in other workloads (Manhattan has a handful of shaders with statically non-uniform discard statements which actually perform better in SIMD32 mode due to their approximate dynamic uniformity). For that reason this change is applied to Gen12+ platforms only. I've been running a number of tests trying to understand the difference in behavior between Gen12 and earlier platforms, and most of the evidence I've gathered seems to point at EU fusion being the culprit: Unlike previous generations, on Gen12 EUs are arranged in pairs which execute instructions in lockstep, giving an effective warp size of 64 threads in SIMD32 mode, which seems to increase the likelihood for control flow divergence in some of the affected shaders significantly. Fixes: 188a3659 "intel/ir: Import shader performance analysis pass." Reported-by:
Caleb Callaway <caleb.callaway@intel.com> Reviewed-by:
Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5910> (cherry picked from commit 4d73988f)
-