- Oct 28, 2021
-
-
Dylan Baker authored
-
Dylan Baker authored
-
- Oct 27, 2021
-
-
Marcin Ślusarz authored
INTEL_DEBUG is defined (since 4015e187) as: #define INTEL_DEBUG __builtin_expect(intel_debug, 0) which unfortunately chops off upper 32 bits from intel_debug on platforms where sizeof(long) != sizeof(uint64_t) because __builtin_expect is defined only for the long type. Fix this by changing the definition of INTEL_DEBUG to be function-like macro with "flags" argument. New definition returns 0 or 1 when any of the flags match. Most of the changes in this commit were generated using: for c in `git grep INTEL_DEBUG | grep "&" | grep -v i915 | awk -F: '{print $1}' | sort | uniq`; do perl -pi -e "s/INTEL_DEBUG & ([A-Z0-9a-z_]+)/INTEL_DBG(\1)/" $c perl -pi -e "s/INTEL_DEBUG & (\([A-Z0-9_ |]+\))/INTEL_DBG\1/" $c done but it didn't handle all cases and required minor cleanups (like removal of round brackets which were not needed anymore). Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Part-of: <mesa/mesa!13406>
-
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com> Part-of: <mesa/mesa!13552>
-
"I think we want to lower them." -Jason "And I do know how the pass works" Ekstrand fixes #5540 cc: mesa-stable Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Part-of: <mesa/mesa!13489> (cherry picked from commit b0c40bc9)
-
the uint[1] -> uint dance is only relevant on the first load, so move the variable type shuffling inside the create block to avoid breaking successive loads fixes #5543 cc: mesa-stable Reviewed-by: Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!13488> (cherry picked from commit 8899f6a1)
-
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 9fa1cdfe ("intel/rt: Implement push constants as global memory reads") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Part-of: <mesa/mesa!13529> (cherry picked from commit a6031cd9)
-
a resource can be bound to multiple fb attachments, each with its own clear, so ensure that all of these are applied fixes #5542 cc: mesa-stable Reviewed-by: Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!13491> (cherry picked from commit dabe477b)
-
We need to know the internal (physical) formats used for AFBC of a given logical format, in order to check format compatibility and determine if we need to decompress AFBC for conformance. Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Cc: mesa-stable Part-of: <mesa/mesa!13205> (cherry picked from commit 93c9123c)
-
Cc: mesa-stable Closes: mesa/mesa#5071 Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!13312> (cherry picked from commit bbce747a)
-
Otherwise, the game refuses to start on xwayland. Cc: mesa-stable Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!13289> (cherry picked from commit b34a3459)
-
When compiling for x86 with MSVC, Vulkan API entry points follow the __stdcall convention (VKAPI_CALL maps to __stdcall), which uses the following name mangling: _<function_name>@<arguments_size> Fix the vk_entrypoint_stub()/alternatename definitions accordingly. Fixes: 6d44b21d ("vulkan: Fix weak symbol emulation when compiling with MSVC") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jesse Natalie <jenatali@microsoft.com> Part-of: <mesa/mesa!13516> (cherry picked from commit 1813bb59)
-
Dylan Baker authored
-
The gl_FragColor lowering in the fragment shader depends on the number of render targets, which can change every set_framebuffer_state. set_framebuffer_state thus needs to force a rebind of the fragment shader. Fixes a regression in Piglit fbo-drawbuffers-none gl_FragColor -auto -fbo from enabling AFBC on Mali G52. Fixes: 28ac4d1e ("panfrost: Call nir_lower_fragcolor based on key") Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Part-of: <mesa/mesa!13498> (cherry picked from commit e0335ad8)
-
This uses the new property for AFBC we've added. The AFBC quirk is applied only to v4, and we only set dev->has_afbc on v5+ so this is not a regression. It now respects the hardware-specific AFBC disable. Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Cc: mesa-stable Part-of: <mesa/mesa!13497> (cherry picked from commit 68a7fafe)
-
AFBC is an optional feature on Bifrost. If it is missing, a bit will be set in the poorly named AFBC_FEATURES register. Check this so we can act appropriately. Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Cc: mesa-stable Part-of: <mesa/mesa!13497> (cherry picked from commit 3e168b97)
-
Fixes: 22f6624e - gallium: separate indirect stuff from pipe_draw_info Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Part-of: <mesa/mesa!13471> (cherry picked from commit 520300ad)
-
Dylan Baker authored
-
- Oct 20, 2021
-
-
Instead of doing a tile cache flush after slow clears or when the clear value changes, do it before every fast clear of a HIZ_CCS_WT surface. This agrees with the Bspec. Fixes: c85ea824 ("iris: reduce redundant tile cache flushes") Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com> Part-of: <mesa/mesa!11539> (cherry picked from commit d7e83644)
-
Without adding `PIPE_CONTROL_TILE_CACHE_FLUSH` into `iris_emit_pipe_control` gen12+ (UHD 750 in my case) has issues with textures. Related-to: mesa/mesa#5029 Fixes: c85ea824('iris: reduce redundant tile cache flushes') Signed-off-by: Mykhailo Skorokhodov <mykhailo.skorokhodov@globallogic.com> Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com> Part-of: <mesa/mesa!12979> (cherry picked from commit 0523607e)
-
Fixes: bd2662bf - mesa: add KHR_no_error support to glUniform*() functions Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <mesa/mesa!13417> (cherry picked from commit 03186773)
-
Annotated <pthread.h> exposes too many errors in Mesa that are non-trivial to fix and keep working without FreeBSD CI. Fixes: 0d5fe24c ("macros: Add thread-safety annotation macros") Reviewed-by: Eric Engestrom <eric@engestrom.ch> Cc: mesa-stable Part-of: <mesa/mesa!9168> (cherry picked from commit 60b7c3a0)
-
gotta get those holes for caching cc: mesa-stable Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!13410> (cherry picked from commit e6655898)
-
Dylan Baker authored
-
- Oct 18, 2021
-
-
Instead of only using the viewport extent. Closes: mesa/mesa#5344 Cc: mesa-stable Reviewed-by: Marek Olšák <marek.olsak@amd.com> Part-of: <mesa/mesa!13382> (cherry picked from commit 234c69f6)
-
This fixes CLs 1.2 1Darray and 2Darray images. Fixes: 589d918a ("spirv: Add 0.5 to integer coordinates for OpImageSampleExplicitLod") Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!13401> (cherry picked from commit f6ecd284)
-
the increment needs to happen before the comparison here Fixes: 3d6c8829 ("aux/pb: add a tolerance for reclaim failure") Reviewed-by: Marek Olšák <marek.olsak@amd.com> Part-of: <mesa/mesa!13388> (cherry picked from commit fe2674dd)
-
originally, a slab attempts to reclaim a single bo. there are two outcomes to this which can occur: * the bo is reclaimed * the bo is not reclaimed if the bo is reclaimed, great. if the bo is not reclaimed, it remains at the head of the list until it can be reclaimed. this means that any bo with a "long" work queue which makes it into a slab will effectively kill the entire slab. in a benchmarking scenario, this can occur in rapid succession, and every slab will get 1-2 suballocations before it reaches a bo that blocks long enough for a new slab to be needed. the inevitable result of this scenario is that all memory is depleted almost instantly, all because pb assumes that if the first bo in the reclaim list isn't ready, none of them can be ready for drivers like radeonsi, this happens to be a fine assumption for drivers like zink, this is entirely not workable and explodes the gpu Cc: mesa-stable Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com> Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Tested-by: Witold Baryluk <witold.baryluk@gmail.com> Part-of: <mesa/mesa!13345> (cherry picked from commit 3d6c8829)
-
Dylan Baker authored
-
- Oct 15, 2021
-
-
Scratch patching code in iris_upload_dirty_render_state (see MERGE_SCRATCH_ADDR calls) assumes that in all shader stages derived_data field stores 3DSTATE_XS packet first. This is not true for TESS_EVAL (DS), so we end up patching 3DSTATE_TE instead of 3DSTATE_DS leading to DWordLength becoming 11 instead of 9 (9 == 3DSTATE_DS.DWordLength, 2 == 3DSTATE_TE.DWordLength, and 9|2 == 11), and hardware hanging on the next instruction. Fix this by reversing the order of packets for TESS_EVAL stage. Closes: mesa/mesa#5499 Fixes: 4256f7ed ("iris: Fill out scratch base address dynamically") Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <mesa/mesa!13358> (cherry picked from commit 5387522b)
-
When eglReleaseThread() is called from application's destructor (API with __attribute__((destructor))), it crashes due to invalid memory access. In this case, _egl_TLS is freed in the flow of _eglAtExit() as below but _egl_TLS is not set to NULL. _eglDestroyThreadInfo _eglFiniTSD _eglAtExit _run_exit_handlers exit Later when the eglReleaseThread is called from application's destructor, it ends-up accessing the freed _egl_TLS pointer. eglReleaseThread -> in libEGL_mesa eglReleaseThread -> in libEGL(glvnd) destructor() -> App's destructor To resolve the invalid access, setting the _egl_TLS pointer as NULL after freeing it. Reviewed-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Jesse Natalie <jenatali@microsoft.com> Reviewed-by: Tapani Pälli <tapani.palli@intel.com> Cc: mesa-stable Closes: mesa/mesa#5466 Part-of: <mesa/mesa!13302> (cherry picked from commit 796c9ab3)
-
This is a preexisting bug but it was uncovered by 231653ea ("intel/isl: Add a max_buffer_size limit to isl_device") which added an assert(num_elements > 0) for typed buffers. Cc: mesa-stable@lists.freedesktop.org Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <mesa/mesa!13351> (cherry picked from commit 393fda2d)
-
Dylan Baker authored
-
- Oct 14, 2021
-
-
If we don't do that we hit the assert(entry[i] != NULL) added by commit 6d44b21d ("vulkan: Fix weak symbol emulation when compiling with MSVC"). Fixes: 6d44b21d ("vulkan: Fix weak symbol emulation when compiling with MSVC") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jesse Natalie <jenatali@microsoft.com> Part-of: <mesa/mesa!13355> (cherry picked from commit fd467492)
-
Mapping unimplemented entrypoints to a global function pointer variable initialized to NULL is a bit cumbersome, and actually led to a bug in the vk_xxx_dispatch_table_from_entrypoints() template: the !override case didn't have the right check on the source table entries. Instead of fixing that case, let's simplify the logic by creating a stub function and making the alternatename pragma point to this stub. This way we get rid of all those uneeded xxx_Null symbols/variables and simplify the tests in vk_xxxx_dispatch_table_from_entrypoints(). Cc: mesa-stable Fixes: 98c622a9 ("vulkan: Update dispatch table gen for Windows") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Jesse Natalie <jenatali@microsoft.com> Part-of: <mesa/mesa!13348> (cherry picked from commit 6d44b21d)
-
If the ISL caller didn't specify a row_pitch_B, let's use the NVIDIA/AMD requirements. Otherwise keep using the Intel requirement, as the caller is likely trying to import a buffer and if we can deal with that row_pitch_B, we should accept it. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: a3a4517f ("isl: Work around NVIDIA and AMD display pitch requirements") Reported-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Nanley Chery <nanley.g.chery@intel.com> Part-of: <mesa/mesa!13024> (cherry picked from commit 9fb2c847)
-
Otherwise we hit assert in vk_object_base_assert_valid when attemping to create handle from anv_fence with unknown base type. Cc: mesa-stable Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Part-of: <mesa/mesa!13330> (cherry picked from commit d729038c)
-
A refactor dropped one of the frees. Fixes: 380ac288 ("ac: import performance counters from RadeonSI") Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!13322> (cherry picked from commit 4721352f)
-
Two carchase compute shaders (shader-db) and two Fallout 4 fragment shaders (fossil-db) were helped. Based on the NIR of the shaders, all four had structures like for (i = 0; i < 1; i++) { ... for (...) { ... } } All HSW+ platforms had similar results. (Ice Lake shown) total loops in shared programs: 6033 -> 6031 (-0.03%) loops in affected programs: 4 -> 2 (-50.00%) helped: 2 HURT: 0 All Intel platforms had similar results. (Ice Lake shown) Instructions in all programs: 143692018 -> 143692006 (-0.0%) SENDs in all programs: 6947154 -> 6947154 (+0.0%) Loops in all programs: 38285 -> 38283 (-0.0%) Cycles in all programs: 8434822225 -> 8434476815 (-0.0%) Spills in all programs: 191665 -> 191665 (+0.0%) Fills in all programs: 298822 -> 298822 (+0.0%) In the presense of loop unrolling like this, the change in cycles is not accurate. v2: Rearrange the logic in the if-condition to read a little better. Suggested by Tim. Closes: #5089 Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> Part-of: <mesa/mesa!13323> (cherry picked from commit ae99ea6f)
-
Dylan Baker authored
-