Since 9254fb4fc7, the pass replaced the SCC clobber with the scalar
identity temporary. Just skip most of the temporary setup, since we don't
need it for gfx10_wave64_bpermute.
Although shuffles are disabled on GFX10, Detroit: Become Human seems to
use them anyway.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-By: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 9254fb4fc7 ('aco: don't use a scalar
temporary for reductions on GFX10')
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3683>
(cherry picked from commit 20eb1acb6f)
This fixes two issues:
- a crash if the application uses more than one semaphore for presenting because the driver expects one stage per semaphore
- the swapchain image could be not ready yet if the semaphores aren't signaled, #946 is possible related
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3718>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3718>
(cherry picked from commit 1c79afd946)
A previous commit ("winsys/svga: Limit the maximum DMA hardware buffer
size") made banded DMA transfer kick in when transfering gnome-shell
window contents under gnome-shell / wayland. This uncovered a bug where
we assumed that banded DMA transfers always occur to the top (y=0) of the
surface.
Fix this by taking the destination y offset into account.
Cc: 19.2 19.3 20.0 <mesa-stable@lists.freedesktop.org>
Fixes: 287c94ea49 ("Squashed commit of the following:")
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3733>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3733>
(cherry picked from commit 451cf228d5)
This param is only available starting on kernel 4.1. Use a default
value of 0 if it is not found instead.
v2: Update commit message (Lionel)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Mark Janes <mark.a.janes@intel.com>
Fixes: 96e1c945f2 ("i965: Move device info initialization to common
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3727>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3727>
(cherry picked from commit 4aa7af9e9a)
We've been missing this workaround for a while and since it's required
for Gen12, let's implement it for Gen9 first.
v2: Update comment for Gen9.
v3: Fix clearing of bits... (Lionel)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3405>
(cherry picked from commit 8949d27bb8)
The extra bits in CB_SHADER_MASK break dual source blending in
SkQP on a Stoney device. However:
- As far as I can tell, some other dual source blend tests are passing
before and after the change.
- A hacked around skqp passes on my Vega desktop and Raven laptop
- Getting Skqp to give any useful info or to run it outside of Android
on ChromeOS is proving difficult.
I have confirmed 3 strategies that seem to work:
- The old radv behavior of setting CB_SHADER_MASK to 0xF
- AMDVLK: CB_SHADER_MASK = 0xFF, and the 3 RB+ regs
are 0.
- radeonsi: CB_SHADER_MASK = 0xFF, but does not set DISABLE
bits in SX_BLEND_OPT_CONTROL for CB 1-7.
Let us use the radeonsi solution as that solution also seems like the correct
thing to do for holes. I have tested on my Raven laptop that setting the high
surfaces to not disabled and downconvert to 32_R does not imply a performance
penalty.
Fixes: e9316fdfd4 "radv: fix setting CB_SHADER_MASK for dual source blending"
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3670>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3670>
(cherry picked from commit 65a6dc5139)
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2464
Fixes: e62c3cf350 ("util/os_socket: Include unistd.h to fix build error")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com>
(cherry picked from commit d1165ad18b)
Otherwise there will be a warning:
"libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering."
Happens with EGL_KHR_surfaceless_context:
eglMakeCurrent(egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE, egl_context)
eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context)
glFlush() // Here will be a warning
Cc: <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1525
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3628>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3628>
(cherry picked from commit 36126b6211)
Destroy rsc->pending_ctx set in etna_resource_destroy(), otherwise
the memory is allocated, never free'd, and becomes unreachable. This
fixes a memory leak.
Fixes: 9e672e4d20 ("etnaviv: keep references to pending resources")
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3633>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3633>
(cherry picked from commit c32bd325e7)
When the rendering are is not covering the whole FBO, and the biggest
damage rect is empty, we can have damage.max{x,y} > damage.min{x,y},
which leads to invalid reload boxes.
Fixes: 65ae86b854 ("panfrost: Add support for KHR_partial_update()")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3676>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3676>
(cherry picked from commit b550b7ef3b)
Fixes
In file included from ../src/util/os_socket.c:8:
../src/util/os_socket.h:26:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
ssize_t os_socket_recv(int socket, void *buffer, size_t length, int flags);
seen with gcc version 8.3.0 (Buildroot 2019.11) and uClibc 1.0.32.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Fixes: ef5266ebd5 ("util/os_socket: Add socket related functions.")
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3659>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3659>
(cherry picked from commit e62c3cf350)
This patch fixes this build error with GCC 10.
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_context.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_resource.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_draw.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_bo.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_submit.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_util.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
/usr/bin/ld: src/gallium/drivers/lima/liblima.a(lima_texture.c.o):src/gallium/drivers/lima/lima_util.h:32: multiple definition of `lima_dump_command_stream'; src/gallium/drivers/lima/liblima.a(lima_screen.c.o):src/gallium/drivers/lima/lima_util.h:32: first defined here
Fixes: d71cd245d7 ("lima: Rotate dump files after each finished pp frame")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
(cherry picked from commit 02658df152)
Previously, i965/iris tried to reuse the currently programmed URB config
if it was good enough for BLORP, rather than reprogramming it each time.
However, this will make some things harder on Gen12+ and we've not seen
any performance impact from emitting URB more frequently in ANV.
This makes the blorp <-> driver interface a bit simpler on Gen7+ because
now all the driver has to do is to provide the L3$ config rather than
trying to hand off URB re-config to blorp.
Cc: "20.0" mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3454>
(cherry picked from commit 09e4c33085)
If BLORP is the first thing to execute, we may not have set the L3$
config yet. That's not normally a problem but we're about to add code
to BLORP which will look at brw_context::l3::config and we'd like that
to be initialized. It's also just good practice.
Cc: "20.0" mesa-stable@lists.freedesktop.org
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3454>
(cherry picked from commit 9d05822cb8)
We only calculate them based on device info and never change them so
this seems like a reasonable place to put them. We could also put them
in the context, but that's not accessible from iris_init_*_context.
Cc: "20.0" mesa-stable@lists.freedesktop.org
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3454>
(cherry picked from commit 99f3178a24)
SML is no longer in the L3$ on Gen11+. It's not incredibly clear from
the docs but no Gen11 platforms are in the list of platforms on which
this bit exists. Also, we've been always setting it false on Gen11 in
ANV and i965 thanks to GEN_L3P_SLM being zero with no ill effects.
Cc: "20.0" mesa-stable@lists.freedesktop.org
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3454>
(cherry picked from commit 73434b665b)
According to the BSpec, this should prevent hangs when using shaders
with large URB entries. A more precise fix can be done but it requires
re-arranging URB setup.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3454>
(cherry picked from commit e1bdb127b6)
