Until now the RD dumps were stored in files on a per-device basis, using
the device index but assuming only one Vulkan instance is active. With
multiple active instances, different devices separated across those
instances could end up storing RD dumps into files with the same name.
tu_instance struct now has an index member variable that's assigned upon
creation with an incrementally-increasing global counter value. RD dump
output name now also contains this instance index, avoiding the described
naming collisions.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: f9c4e25483 ("freedreno: add fd_rd_output facilities for gzip-compressed RD dumps")
Reviewed-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30977>
In commit fe3d90aedf ("intel/fs/xe2+: Fix calculation of spill message
width for Xe2 regs.") we aligned the width of scratch messages to
physical register sizes (32B prior to Xe2, 64B for Xe2+).
But our spilling offsets are computed using the register allocations
sizes which are in units of 32B. That means on Xe2, you can end up
spilling a virtual register allocated at 32B (which we use for surface
state computations with exec_all) and then the spilling of that
register will be emitted in SIMD16, having the upper 8 lanes
overwriting the next spilled register.
We could potentially limit spills to SIMD8 messages on Xe2 (only
writing 32B of data), but we're also unlikely to have all 32B virtual
register spilled next to one another. And if not tightly packed, we
would have 64B registers stored on 2 different cachelines which sounds
inefficient.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: fe3d90aedf ("intel/fs/xe2+: Fix calculation of spill message width for Xe2 regs.")
Backport-to: 24.2
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30983>
Since commit 8f6fca89aa ("meson: delete dri3 build option"),
the docs build attempts to find dependencies like xshmfence which
are not found in the current docs image.
Avoid checking for those dependencies by not enabling any platforms,
which will skip the check overall.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31025>
The user must have used INTEL_FORCE_PROBE to force the device to be
loaded, so they specifically opted-in to enabled unsupported device
support.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31011>
The intention here was to get include the common intel_gem.h to
get the intel_ioctl() signature.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31026>
this existed for historical reasons, but realistically now it should
be possible to build mesa with dri3 always enabled. additionally,
this check was often used as a substitute for having drm functionality,
which is sort of similar but also not really a direct match
this simplifies a bunch of conditionals and prevents users from footgunnning
themselves into orbit
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30952>
drivers using renderpass tracking can rely on having
pipe_framebuffer_state::resolve + tc_info::has_resolve to indicate
a winsys blit, which means they don't actually need the blit call
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30772>
When more than one instance of the shader compiler is running at
once, the output of ETNA_MESA_DEBUG=dump_shaders is almost useless
as output from multiple instances will get interleaved, making it
very hard to parse.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30604>
There is no reason to hide the shader machine code on release
builds when ETNA_MESA_DEBUG=dump_shaders is specified. This
debug option will dump lots of NIR already, so the machine
code is in good company.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30604>
While some bits for gl_VertexID were already present in the
compiler, it was still missing in lots of cases. Wire those
up to make gl_VertexID usable.
Fixes piglit spec@!opengl es 3.0@gl_vertexid.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30604>
The idea is to better abstract loading shader metadata parameters by
using the same layout for indirect/non-indirect compute pipelines.
Graphics support will added later.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30987>
Instead of storing the stride/rsrc_word3 as part of the VBO descriptors,
pass them as parameters. This is cleaner and this will allow us
to simplify VBO in DGC.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30918>
For the similar commit c738cfe8 a review comment was:
> The EGL 1.5 changelog says that it incorporates the 3D texture
> extension's methods, but does not seem to require that they succeed.
The same could be said for Reset Notification Strategy and Robust Buffer
Access as implementations seem to be explicitely allowed to not succeed.
The EGL 1.5 spec says:
> "An EGL_BAD_MATCH error is generated if an OpenGL or OpenGL ES
> context is requested with robust buffer access and with a
> specified reset notification behavior, and the implementation
> does not support that behavior."
As we do return these errors accordingly during context creation, stop
requiring drivers to implement successfull creation of robust contexts,
as indicated by the extension.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30764>
