The result buffer is where the kernel places statistics and fault
information after the GPU executes a command. Dummy structure pending
UAPI.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21662>
We expect to forward GPU fault information to userspace. Since Mesa can
get that information, we can look up the fault address to log what was
the containing or nearest BO. Add a helper for that, so it can be called
from the driver.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21662>
With macOS support out of the way, we can start implementing a lot of
the Linux driver interface and bookkeeping without actually adding the
UAPI proper. Let's do that to reduce the size of the UAPI patchset.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21662>
Nothing implemented, but this lets us get the batch tracking bits in,
including explicit sync/DMA-BUF integration which uses generic ioctls.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21662>
This might be useful in the future, but it is best reimplemented in
terms of the upcoming Linux UAPI instead of having parallel codepaths.
Let's drop it.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21662>
Destroy the surface dmabuf feedback proxy before destroying the event
queue that the proxy is attached to.
This silences a warning that libwayland 1.22 emits for programs that use
Vulkan/Wayland:
warning: queue 0x557a4efbcf70 destroyed while proxies still attached:
zwp_linux_dmabuf_feedback_v1@18 still attached
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21647>
Destroy the display wrapper proxy before destroying the event queue that
the proxy is attached to.
This silences a warning that libwayland 1.22 emits for programs that use
EGL/Wayland:
warning: queue 0x562a5ed2cd20 destroyed while proxies still attached:
wl_display@1 still attached
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21646>
We need to have the scratch buffer added to the pipeline BO tracking
list, so it's added to the batch buffer and finally to the execbuffer
list. Otherwise we pagefault (or read the default scratch page on
i915).
Fixes
dEQP-VK.subgroups.ballot_broadcast.graphics.subgroupbroadcast_u16vec4
on CI (and probably other tests).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 2028f1caa3 ("anv: emit 3DSTATE_HS in cmd_buffer_flush_gfx_state")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21653>
Using texelFetch to read samples from an 8xMSAA fast cleared image on
Haswell can read transparent black pixels around triangles from where
there should be none. This issue isn't present when using sample
shading, resolving the image using vkCmdResolveImage or in a copy the
image. The easiest way to fix this is by just disabling non-zero fast
clears for 8xMSAA images.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7587
Cc: mesa-stable
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21444>
Instead, check if the cache is the meta shader cache. This catches the
shaders created by radv_create_radix_sort_u64().
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21606>
For optimalTilingFeatures we should be advertising
STORAGE_IMAGE_BIT for B10G11R11_UFLOAT_PACK32 too.
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21649>
This commit removes the advertising of features that are currently
unsupported by the driver and aren't strictly necessary for
Vulkan 1.0.
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21649>
After cross-checking with kernel and the old buffer copy code, it seems
that the size field should be size - 1 instead.
Fixes: 7b5ab48c40 ("radv: partial sdma support")
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21585>
After cross-checking with kernel and the old buffer copy code, it seems
that the size field should be size - 1 instead.
Fixes: 46c95047bd ("radeonsi: implement si_sdma_copy_image for gfx7+")
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21585>
We are seeing endless DRM_IOCTL_SYNCOBJ_WAIT ioctl when system memory is
under pressured.
Commit f9d8d9acbb ("iris: Avoid abort() if kernel can't allocate
memory") avoids the abort() on ENOMEM by resetting the batch. However,
when there's an ongoing OpenGL query, resetting the batch will make the
snapshots_landed never be flipped, so iris_get_query_result() gets stuck
in the while loop forever.
Since there's no guarantee that the next batch after resetting won't hit
ENOMEM, so instead of resetting the batch, be patient and wait until kernel has
enough memory. Once the batch is submiited and snapshots_landed gets
flipped, iris_get_query_result() can proceed normally.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6851
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20449>
This crashed on Steam Deck because the memory type is LPDDR5 and it
wasn't not handled in the switch. It seems the kernel changed the
memory type returned for VanGogh because it used to work.
Fixes: aef7ea868f ("ac/gpu_info: handle LPDDR4 and 5 in ac_memory_ops_per_clock")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21627>
So that the next person trying to cut down LLVM compile times doesn't trip
over this.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21142>
Again, this should reduce the complexity of the LLVM IR we emit in some
cases. We don't use it for shared loads, due to the noted corner case.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21142>
If we're just loading memory, we can take the scalar offset_is_uniform
paths even the first active invocation is nonzero, saving a bunch of
looping and bounds checking for per-element loads. And, if we don't have
an active invocation, doing the load for element 0 (which is
bounds-checked to return 0 if element 0 had a bad value in it) before
throwing away the result is still better than doing bounds-checked loads
for each element before throwing away the result.
dEQP-VK.ubo.random.16bit.scalar.92 goes from 16.5 to 14.0 seconds.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21142>
gallivm doesn't actuially jump across branches where no invocations are
active, so my previous assertion about the exec mask being nonzero was
incorrect. This means that we'll always use a defined invocation for the
various LLVMBuildExtractElements using the result value, which is an
improvement over my even the code before my cttz change that would use
undefined values for the element to be extracted.
Fixes: 8c2493d041 ("gallivm: Use cttz instead of a loop for first_active_invocation().")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21142>
Workarounds for defects in Intel silicon have been manually
implemented:
- consult defect database for the current platform
- add workaround code behind platform ifdef or devinfo->ver checks
Some bugs have occurred due to the manual process. Typical failure
modes:
- defect database is updated after a platform is enabled
- version checks are overly broad (eg gfx11+) for defects that were
fixed (eg in gfx12)
- version checks are too narrow for defects that were extended to
subsequent platforms.
- missed workarounds
This commit automates workaround handling:
- Internal automation queries the defect database to collate and
summarize defect documentation in json.
- mesa_defs.json describes all public defects and impacted platforms.
Defects which are extended to subsequent platforms are listed under
the original defect.
- gen_wa_helpers.py generates workaround helpers to be called
in place of version checks:
- NEEDS_WORKAROUND_{ID} provides a compile time check suitable for
use in genX routines.
- intel_device_info_needs_wa() provides a more precise runtime
check, differentiating platforms within a generation and
platform steppings.
Internal automation will generate new mesa_defs.json as needed.
Workarounds enabled with these helpers will apply correctly based on
updated information in Intel's defect database.
Reviewed-by: Dylan Baker <dylan@pnwbakers>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20825>
This ensures that users of libintel_dev.a won't be compiled until
include files are generated, and that they are recompiled when the
header changes.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20825>
Performance regressed by 31% in one VP2020/Creo subtest because
the draw_always_async flag wasn't implemented correctly. Remove it
instead of fixing it.
While removing it, I noticed that our DrawIndirect async conditions
were incorrect. I fixed them.
Fixes: 3b897719e6 - glthread: add ctx->GLThread.draw_always_async to simplify draw checking
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21566>
