This will let other drivers use the same way of presenting annotations
without duplicating the whole hash table thing.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22157>
This is way more horrifying than I hoped -- I can't figure out a way to
have the method be on TraceContext, so it's a static method of the
datasource, but then you have to name the templated types over and over.
You have to pass in a TraceContext because intel emits the clock sync
packet within a Trace(), and perfetto just silently corrupts the trace if
you Trace() in a Trace().
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22157>
Deduplicates some code from intel/tu/freedreno, and will be a common place
to put other shared code.
The downside I can see is this logging:
[013.129] tu_perfetto.cc:122 Tracing started
[013.129] intel_driver_ds.cc:133 Tracing started
("oh, huh, apparently data sources for both drivers are registered? wild")
becomes:
[142.906] erfetto_renderpass.h:50 Tracing started
[142.907] erfetto_renderpass.h:50 Tracing started
("huh, why is my driver's data source being started twice?").
Unfortunately we can't easily get a string for the data source type due to
not having rtti.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22157>
I was frustrated trying to write code and not be able to just mash ^K^F to
format what I'd written. This .clang-format is just cargo-cult of turnip
with a few tweaks to reduce the diff to the current directory contents.
The remaining deltas in the reformat look decent to me, and mostly bring
things closer to mesa-vague-consensus style.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22157>
anv_bo_sync_type is only supported with i915, if necessary it will be
implemented for Xe kmd.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22171>
This also need to be executed in Xe kmd, so moving it to a function.
No changes in behavior intended here.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22171>
ftruncate() allocates disk space lazily. If the disk is full and it is
unable to allocate disk space when accesed via mmap(), it will crash
with a SIGBUS.
Switch to posix_fallocate(), which ensures disk space is allocated
otherwise it fails if there isn't enough disk space. The disk cache
won't be enabled in this case.
For normal cases, a small increase in disk usage as the 1.3MB index
file will be fully allocated when initialized now.
fallback to ftruncate() if posix_fallocate() isn't found.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22097>
The conversion pointer has a vk_object_base containing pointers.
Previous commits had a similar issue, storing an internal pointer to
the array of formats in anv_format.c
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22160>
To be helpful, the thing inside the fsat has to be used with and without
the fsat. Otherwise it just moves a saturate destination modifier
around. To not be harmful, the fsat has to only be used by the bcsel.
All Broadwell and newer Intel platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 20174475 -> 20174449 (<.01%)
instructions in affected programs: 3913 -> 3887 (-0.66%)
helped: 13 / HURT: 0
total cycles in shared programs: 866844832 -> 866844719 (<.01%)
cycles in affected programs: 46037 -> 45924 (-0.25%)
helped: 10 / HURT: 1
All Intel platforms had similar results. (Ice Lake shown)
Instructions in all programs: 161491468 -> 161491372 (-0.0%)
helped: 31 / HURT: 8
Cycles in all programs: 10933090736 -> 10933024716 (-0.0%)
helped: 32 / HURT: 18
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22169>
There are already NIR algebraic optimizations (see also ac6646129f
("nir: Move fsat outside of fmin/fmax if second arg is 0 to 1.") that
will try to remove the saturate from things like
fmax(0.5, fsat(x))
This basically reverts 40aeb558ce ("i965/fs: Allow propagation of
instructions with saturate flag to sel"). That commit message had no
shader-db information, so it's unclear whether this actually helped
anything ever.
No shader-db changes on any Intel platform.
One shader in Far Cry New Dawn was affected.
Cycles in all programs: 10933090738 -> 10933090736 (-0.0%)
Cycles helped: 1
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22169>
Avoid looping by using the new `parent` field to check if a generaetd gs
is bound and use `bind_gs_state` insted of `bind_gfx_stage` so that
`bind_last_vertex_stage` is automatically called
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21238>
For a generated gs this field will store a pointer to the shader that
"owns" it.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21238>
If the same vertex shader is used for more than one pipeline where for some a gs
is generated but not for others then the logic to free pipeline
libraries might use the incorrect stage_mask and try to free a non
existing gs.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21238>
Zink now exposes the `PIPE_PRIM_QUADS` among supported primitives and
handles them with geometry shaders.
Previously, while not exposing this capability, gallium would internally
generate an index buffer to draw them with triangles.
However the information necessary to avoid drawing the diagonal line
when using the line primitive was not preserved.
fails are added for wireframe xfb quads tests
xfb is expected to output tessellatated quads while showing a quad
without a diagonal, however there is no sane way of achieving this.
As part of the test quads will be rendered with and without xfb and the
results compared.
Now to avoid breaking xfb zink has to always split quads into triangles
when xfb is enabled. This means that the test will fail.
Previously the diagonal was always present so the test passed
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21238>
Zink will now handle flat interpolation correctly when line loops
are generated from primitives.
The flat shading information is passed to the emulation gs using constant
uniforms which get inlined.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21238>