The DRI wiki is a wasteland at this point, let's just fold the one bit of
useful information in here.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5507>
A bit cleaner than open coding the list manipulation. Plus I want to
use it in the next patch, rather than adding more open coded list
futzing.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5280>
When a sequence of same instruction is encoded with repeat flag,
destination registers are written on successive cycles. Teach the
delay calculation about this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5280>
These two encodings are mutually exclusive. If the instruction is a
vector(ish) `(rptN)` instruction, then we can't fold a `(nopN)` post-
delay into it.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5280>
In the `try_swap_mad_two_srcs()` case, valid_flags() gets called both
for the src that we want to try to fold, and for the other src that we
are trying to swap to make that possible. It can happen in the 2nd case
that a RELATIV src has already been folded. Since `ssa()` returns non-
null in both the `IR3_REG_SSA` and `IR3_REG_ARRAY` cases (in the later
case, it is the dependent array access that the current instruction
cannot be moved ahead of), we need to explicitly check that the src
reg we are looking at is still an SSA src.
Reported-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5280>
We also need to clear the table of compute times at the end of the
frame, otherwise results shown will include all the compute jobs since
the beginning of the trace.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5280>
I don't think Mesa 4.0 swrast conformance is relevant at this point, just
point people to the current Khronos list. Also, add some more information
on submitting results.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5482>
Those are currently hurting Felix' ability to look at the batches.
We can probably detect this in the aubinator but that's a bit more
work than falling back to the previous behavior.
v2: Condition VK_KHR_performance_query to not using this variable (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5391>
All the other driver-specific intrinsics are at the end of the file so
Intel's should go there too.
Reviewed-by: Sagar Ghuge<sagar.ghuge@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5503>
If submitting for conformance it is probably better to have a generic
name for vendor here.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5483>
virgl vendor id should probably be little more generic now.
I think I picked this becuase the virtio pci id space was under
RH's name and they did pay for it, but at this point I think it's
better to just use something generic.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5483>
This cleans up pipline create/destroy a bit after the compute/gfx split.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5457>
The approach taken in this commit only works on drivers that expose
the PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT capability. For drivers
that don't, the buffer has been unmapped by the time we get to
hud_draw_colored_prims, leading to crashes.
It's not easy to fix the code, but drivers that do support coherent
mapping will most likely do the right think themseleves, so let's just
go back to using user-buffers here.
This reverts commit 4fe1fd4df4.
Fixes: 4fe1fd4df4 ("gallium/hud: don't use user vertex buffers")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3106
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5417>
Validate that num_components is only set for vectorized instructions, to
prevent other nir passes or driver backends from mistakenly relying on
num_components for non-vectorized instructions.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5371>
Of the possible intrinsics generated, only load_ssbo is vectorized (and
store_ssbo is never generated)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5371>
It is better to use `nir_intrinsic_dest_components()` which also handles
the case of intrinsics with a fixed number of dest components.
Somehow this starts showing up with a nir_serialize round-trip with
shader-cache. But we really shouldn't have been relying on
`intr->num_components` directly.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5371>
