Since b167203cfe ("mesa/st: Always generate NIR from GLSL, and use
nir_to_tgsi for TGSI drivers."), it's always set in the context.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
The GL frontend is about to start only querying against NIR, since it only
generates NIR.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
Now that we don't have to generate TGSI, we can drop an indirection.
Fixing up the types here prompted a little fixup of
st_nir_make_passthrough_shader()'s types.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
Now everyone's saying NIR, and doing any NTT internally. The only returns
of TGSI were in gallivm_get_shader_param() and
tgsi_exec_get_shader_param(), but the drivers were returning NIR instead
of calling down to them.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
The flag has been here for a long time, it's time for SVGA to start
ingesting NIR like other drivers do.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
The NIR path is default, and well-trodden at this point. By dropping
support for input as TGSI, we get rely on the NIR trig lowering.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
We lower to TGSI inside the driver just fine, no need to ask the frontend
for it.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
Now that everyone but SVGA is requesting NIR, this path had been
effectively disabled. I had done a partial port of the VS side in
9143c08125 ("st/nir: Fix the st->pbo.use_gs case.") for the sake of
nv50, but with it should be ready for all drivers. Affects nv50, v3d,
d3d12, svga (I think).
Note that this GS code is slightly different from the TGSI: We put a 0 in
pos.z, rather than leaving the layer value there, because apparently v3d
didn't like those denorm Z values.
Also, it's nice to see that the NIR code is shorter than the TGSI code
was, we've made great progress on nir_builder.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
In most VS creation paths in the frontend, nir_lower_io_to_temporaries()
is called, which ensures that all outputs have a single write to them
(with a full writemask). The builtins don't, however, and this VS was an
oddball that overwrote one channel of an output that it had already
written. We can avoid surprises for backends (such as d3d12 and v3d) by
emitting a single write per output here.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
Usually lower_io_to_temps sorts this out for us so you only get full
writes, but we should be able to handle it without that. Avoids a
regression with the mesa/st PBO VS with layer output.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23114>
Indeed, this function was not processing the linked
allocated list.
For instance, this issue is triggered with "piglit/bin/hiz-depth-read-fbo-d24-s0 -auto":
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f6795638987 in calloc (/usr/lib64/libasan.so.6+0xb1987)
#1 0x7f678bac13b9 in nouveau_heap_alloc ../src/gallium/drivers/nouveau/nouveau_heap.c:64
#2 0x7f678bb6c7e4 in nv50_program_upload_code ../src/gallium/drivers/nouveau/nv50/nv50_program.c:490
#3 0x7f678bb83b92 in nv50_vertprog_validate ../src/gallium/drivers/nouveau/nv50/nv50_shader_state.c:161
#4 0x7f678bba3000 in nv50_state_validate ../src/gallium/drivers/nouveau/nv50/nv50_state_validate.c:552
#5 0x7f678bba3c4d in nv50_state_validate_3d ../src/gallium/drivers/nouveau/nv50/nv50_state_validate.c:575
#6 0x7f678b9e3e92 in nv50_blit_3d ../src/gallium/drivers/nouveau/nv50/nv50_surface.c:1444
#7 0x7f678b9e3e92 in nv50_blit ../src/gallium/drivers/nouveau/nv50/nv50_surface.c:1832
#8 0x7f678a0b378a in blit_to_staging ../src/mesa/state_tracker/st_cb_readpixels.c:337
#9 0x7f678a0b7358 in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:516
#10 0x7f6789f82005 in read_pixels ../src/mesa/main/readpix.c:1178
#11 0x7f6789f82005 in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1195
#12 0x7f6789f82ac0 in _mesa_ReadPixels ../src/mesa/main/readpix.c:1210
...
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
Fixes: 67635a0a71 ("nouveau: get rid of tabs")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23592>
split ANV_PIPE_RENDER_TARGET_BUFFER_WRITES into separate CS_STALL,
RT_FLUSH & TILE_FLUSH flags in order to have finer control over cache
coherency.
Tigerlake CS has it's own cache fetching directly from the memory controller,
so we need to do a tile flush to ensure the query data is visible.
This fixes test_resolve_non_issued_query_data in vkd3d on TGL.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Fixes: 3c4c18341a ("anv: narrow flushing of the render target to buffer writes")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23500>
When an exec write isn't used but writes other registers
besides exec, and also reads exec (such as s_and_saveexec),
we would mistakenly delete the previous instruction that
writes the exec value that this instruction uses.
No Fossil DB changes on Rembrandt (GFX10.3).
Fixes: 0211e66f65
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9036
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23576>
There was a race between the worker thread and flush, which could lead to
the last event flushed getting its status set to CL_SUCCESS before any
other event.
Just wait on all flushed events in order to solve this.
The current queue/event implementation isn't the best and we want to
rework it, so this is good enough for now.
Fixes: 47a80d7ff4 ("rusticl/event: proper eventing support")
Signed-off-by: Karol Herbst <git@karolherbst.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23578>
The only part we strictly need repr(C) is in `CLObjectBase` and we already
didn't have it set for `Device` and it worked just fine.
We keep it on in `Platform` as this is a more hand rolled type and less
relevant.
With this we can make use of Rusts data layout which saves us some memory.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23573>
With MTL onwards, creating protected contexts too early
may block for a longer period. To prevent that, use the new
kernel GET_PARAM:I915_PARAM_PXP_STATUS interface to get the
status of PXP support immediately without blocking.
Using this same interface, we can also wait for platform
dependency readiness before attempting to create a protected
context. Use a longer timeout when user explicitly requests
for protected context as the kernel assures readiness will be
achieved.
Reference to kernel change: https://patchwork.freedesktop.org/patch/533241/?series=112647&rev=8
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23382>
NOTE: skipped AMD header update due to build error.
From drm-next at the following commit:
commit 2e1492835e439fceba57a5b0f9b17da8e78ffa3d
Merge: 85d712f033d2 43049f17b526
Author: Dave Airlie <airlied@redhat.com>
Date: Fri Jun 2 13:38:48 2023 +1000
Merge tag 'drm-misc-next-2023-06-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23382>
In order to prioritize the upcoming pre-merge jobs on VanGogh, we
limit all the post-merge jobs requiring VanGogh runners to the
low-priority pool of runners.
This will allow Marge to use any of the VanGogh runners we have (6),
while leaving 3 of them unused by post-merge jobs inside Mesa, or
DXVK-CI.
Suggested-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23548>
When we have many DUTs with the same tags (or subset of tags), it is
possible for the gitlab runner name not to match the DUT picked by
valve-infra's executor.
This is needlessly confusing, and prevents specifically tagging some
runners with a low-priority tag but still have these runners execute
high-priority jobs... because a low priority job may get started by
gitlab but the corresponding DUT is being used by a high-priority
task.
To fix this, simply tell the executor which DUT we want, not just the
list of tags we want.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23548>
Fix defect reported by Coverity Scan.
Self assignment (NO_EFFECT)
self_assign: Assigning sh->info.fs.depth_layout to itself has no effect.
Fixes: bbd265b8e8 ("r600+sfn: Assign ps_conservative_z and switch to NIR defines")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23414>
The texture resource has just been allocated for the whole purpose
of holding the drawpixels data. Make the drivers life a bit easier
by telling it that we aren't interested in any previous content
when mapping the resource.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23546>
Same as the transfer flushes, the flushes caused by waiting for
a query result don't need to realize context external visibility
of resource changes and can thus be a bit more lightweight.
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/23557>
The real maximium for the occlusion query samples is much higher
than what the code currently claims to support as we always
allocate a full 4KB buffer to store the query results.
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/23557>
The real maximium for the perfmon samples is much higher than
what the code currently claims to support as we always allocate
a full 4KB buffer to store the query results.
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/23557>
The allocated query buffer is always 4KB in size and can hold
a variable number of samples depending on the sample size.
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/23557>
ARB_occlusion_query specifies that the query is reset on BeginQueryARB,
not when the fetching the result of the query. This behavior also makes
a lot of sense for the perfmon queries.
CC: mesa-stable
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/23557>
Different query providers have different behavior on when they produce
samples: the perfmon provider provides a sample at the start and at the
end of the query, while the occlusion query provider only adds another
sample when the query is complete.
Move the sample count manipulation to the providers to be able to take
those differences into account. Removes a useless always-zero sample
for each OQ resume/suspend pair.
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/23557>
It's unclear why this is needed, but PAL uses RESET_FILTER_CAM
for some mesh shading draw packets:
- DISPATCH_MESH_INDIRECT_MULTI
- DISPATCH_TASKMESH_GFX
Let's do the same in radv.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23554>
Equivalent of 284e604872 but for acceleration structure queries.
If an app inserts a barrier between AS builds and writing AS properties,
we must respect it or things will blow up.
Cc: mesa-stable
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23568>
radeonsi switched over to CU wavefront execution mode, but didn't tell
LLVM. This can lead to shaders requiring too many VGPRs to be executed in
CU mode and so cause GPU resets.
Pass along +cumode to LLVM so it properly spills VGPRs.
Fixes: 9d7eab2ab1 ("radeonsi: don't enable WGP_MODE because of high cost of workgroup mem coherency")
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23569>
PIPE_FUNC_ -> COMPARE_FUNC_
pipe_compare_func -> compare_func
Now include "pipe/p_state.h" is not needed and remove it in ac_nir.h
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23422>
