The script will be used for tuning Intel GPU frequency to maximize
performance tests execution, while also trying to reduce throttling,
which has a negative impact on results consistency.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15662>
Add script to manage Intel GPU frequencies.
It can be used for debugging performance problems or to lock a stable
frequency while executing benchmark tests.
Typical use cases:
- Get all available GPU frequency information
$ ./intel-gpu-freq.sh -g all
* Hardware capabilities
RP0: 1350 MHz
RPn: 100 MHz
RP1: 400 MHz
* Enforcements
max: 1350 MHz
min: 100 MHz
boost: 1350 MHz
* Actual
act: 100 MHz
cur: 400 MHz
- Lock frequency to 80% of the maximum allowed by hardware and enable
throttling detection
$ ./intel-gpu-freq.sh -s 80% -d
GPU throttling detected: act=1050 min=1350 cur=1350 RPn=100
GPU throttling detected: act=1100 min=1350 cur=1350 RPn=100
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15662>
Vulkan spec says:
"When an image view of a depth/stencil image is used as a depth/stencil
framebuffer attachment, the aspectMask is ignored and both depth and
stencil image subresources are used."
Since we use two planes for D32S8 format we have to add a special
case for depth in addition to already existing case for stencil.
Fixes hang in CTS:
dEQP-VK.renderpass.depth_stencil_write_conditions.stencil_kill_write_d32sf_s8ui
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15532>
- When resolving d32s8 to s8 we stored stencil with a wrong format.
- For unaligned multi-sample store we used wrong gmem offset for stencil.
If unaligined store is forced this change fixes a hang in:
dEQP-VK.renderpass2.depth_stencil_resolve.image_2d_32_32.samples_2.d32_sfloat_s8_uint_separate_layouts.compatibility_depth_zero_stencil_zero_testing_stencil
Fixes: b157a5d0d6
("tu: Implement non-aligned multisample GMEM STORE_OP_STORE")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15532>
This has been initially implemented for raytracing but
VK_EXT_graphics_pipeline_library requires it.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15737>
this interaction requires read-only sampler access from
depth component with writes to the stencil component, which can only
be done in the GENERAL layout
affects:
GTF-GL46.gtf30.GL3Tests.framebuffer_blit.framebuffer_blit_functionality_color_and_stencil_blit
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15716>
ssbo binds are always at least readable, so without deeper shader
inspection, never assume that write binds mean no read access
this is different than image descriptors which can explicitly get
write-only access set
cc: mesa-stable
fixes#6231
THANKS TO @daniel-schuermann FOR SOLVING THIS WITH HIS INCREDIBLE TALENT AND WIT
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15697>
They're both implemented in common code as long as you use
vk_command_buffer.
Acked-by: Emma Anholt <emma@anholt.net>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15560>
The common Vulkan sync framework will do most of the queueing for us.
It will even sort out timeline semaphore dependencies and ensure
everything executes in-order. All we have to do is make sure our
vk_sync type implements VK_SYNC_FEATURE_WAIT_PENDING. This lets us get
rid of a big pile of code.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15651>
To avoid altering any currently existing callers, we continue on with
the calculation regardless of overflow. This also matches the behavior
of GCC's __builtin_add_overflow().
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15651>
dEQP-VK.binding_model.buffer_device_address.set3.depth3.basessbo.convertuvec2.nostore.multi.scalar.vert
runtime -24.4002% +/- 1.94375% (n=7). The win (I think) is in LLVM not
having to chew through handling the extra loops on every constant-offset
SSBO load, not in actual rendering time.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
If we know the offset is constant, we don't have ask LLVM to loop over the
elements pulling the same value out over and over.
This doesn't seem to have produced a win in the testcase I was looking at,
but it was an easier entrypoint to figuring out how to do scalar memory
access than load_memory, and will probably affect some workload.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
In a fragment shader or inside of control flow, invocation 0 might be
inactive, and so our use-first-invocation-and-broadcast optimizations
would be invalid, and the loop logic of an emit_read_invocation would
defeat the point of these optimized paths.
For load_kernel_input, I didn't guard the uniform path with the check
because some CL tests that are currently passing are doing the
load_kernel_input under (presumably) uniform control flow. Instead, I
dropped in a once warning for the next person to be debugging CL.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
These are not data-race safe (like many other once patterns in Mesa), so
they might not log exactly once, but it should be good enough for not
spamming the console.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14999>
We already have a way to pass env vars around, just use that instead of
packing/unpacking it on the kernel command line.
Cleans up HW runner job log output some more.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
This should help highlight the actual test results, as opposed to the setup
and teardown.
Also tuned the "set -x"es a little bit so we get less surrounding noise in
the echo process.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
VK-GL-CTS causes tons of these due to a bug in glslang, to the point where
it's hard to find actual issues in test logs. Disable the warning for
now, with a link to the issue we're waiting on being resolved.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15332>
Cristian Ciocaltea
Lionel Landwerlin
Vadym Shovkoplias
Danylo Piliaiev
Samuel Pitoiset
Mike Blumenkrantz
Renato Pereyra
Jason Ekstrand
Emma Anholt