The is_partial_write check is too strict because it tests two separate
things. It tests whether or not the instruction always writes a value
(i.e., is it predicated), and it tests whether or not the instruction
writes a complete register. This latter check is problematic as it
perevents cmod propagation in SIMD1, and it prevents cmod propagation in
SIMD8 when the destination size is 16 bits.
This check is unnecessary. Cmod propagation already checks that the
region written and region read overlap. It also already checks that the
execution sizes of the instructions match. Further restriction based on
the specific parts of the register written only generates false
negatives.
v2: Relax all of the calls to is_partial_write. Suggested by Caio.
No shader-db changes on any Intel platform.
fossil-db:
Meteor Lake
Totals:
Instrs: 151505520 -> 151502923 (-0.00%); split: -0.00%, +0.00%
Cycle count: 17201385104 -> 17194901423 (-0.04%); split: -0.06%, +0.02%
Spill count: 80827 -> 80837 (+0.01%)
Fill count: 152693 -> 152692 (-0.00%); split: -0.01%, +0.01%
Totals from 346 (0.05% of 630198) affected shaders:
Instrs: 1257205 -> 1254608 (-0.21%); split: -0.21%, +0.00%
Cycle count: 5532845647 -> 5526361966 (-0.12%); split: -0.18%, +0.06%
Spill count: 32903 -> 32913 (+0.03%)
Fill count: 64338 -> 64337 (-0.00%); split: -0.03%, +0.03%
DG2
Totals:
Instrs: 151531440 -> 151528055 (-0.00%); split: -0.00%, +0.00%
Cycle count: 17200238927 -> 17197996676 (-0.01%); split: -0.03%, +0.02%
Spill count: 81003 -> 80971 (-0.04%); split: -0.04%, +0.00%
Fill count: 152975 -> 152912 (-0.04%); split: -0.05%, +0.01%
Totals from 346 (0.05% of 630198) affected shaders:
Instrs: 1260363 -> 1256978 (-0.27%); split: -0.27%, +0.00%
Cycle count: 5532019670 -> 5529777419 (-0.04%); split: -0.09%, +0.05%
Spill count: 33046 -> 33014 (-0.10%); split: -0.11%, +0.01%
Fill count: 64581 -> 64518 (-0.10%); split: -0.13%, +0.03%
Tiger Lake and Ice Lake had similar results. (Tiger Lake shown)
Totals:
Instrs: 149972324 -> 149972289 (-0.00%)
Cycle count: 15566495293 -> 15565151171 (-0.01%); split: -0.01%, +0.00%
Totals from 16 (0.00% of 629912) affected shaders:
Instrs: 351194 -> 351159 (-0.01%)
Cycle count: 3922227030 -> 3920882908 (-0.03%); split: -0.04%, +0.00%
Skylake
Totals:
Instrs: 140787999 -> 140787983 (-0.00%); split: -0.00%, +0.00%
Cycle count: 14665614947 -> 14665515855 (-0.00%); split: -0.00%, +0.00%
Spill count: 58500 -> 58501 (+0.00%)
Fill count: 102097 -> 102100 (+0.00%)
Totals from 16 (0.00% of 625685) affected shaders:
Instrs: 343560 -> 343544 (-0.00%); split: -0.01%, +0.01%
Cycle count: 3354997898 -> 3354898806 (-0.00%); split: -0.01%, +0.01%
Spill count: 16864 -> 16865 (+0.01%)
Fill count: 27479 -> 27482 (+0.01%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
The specific pattern from the unit test was observed in ray tracing
trampoline shaders.
v2: Refactor the is_raw_move tests out to a utility function. Suggested
by Ken.
v3: Fix a regression caused by being too picky about source
modifiers. This was introduced somewhere between when I did initial
shader-db runs an v2.
v4: Fix typo in comment. Noticed by Caio.
shader-db:
All Intel platforms had similar results. (Meteor Lake shown)
total instructions in shared programs: 19734086 -> 19733997 (<.01%)
instructions in affected programs: 135388 -> 135299 (-0.07%)
helped: 76 / HURT: 2
total cycles in shared programs: 916290451 -> 916264968 (<.01%)
cycles in affected programs: 41046002 -> 41020519 (-0.06%)
helped: 32 / HURT: 29
fossil-db:
Meteor Lake, DG2, and Skylake had similar results. (Meteor Lake shown)
Totals:
Instrs: 151531355 -> 151513669 (-0.01%); split: -0.01%, +0.00%
Cycle count: 17209372399 -> 17208178205 (-0.01%); split: -0.01%, +0.00%
Max live registers: 32016490 -> 32016493 (+0.00%)
Totals from 17361 (2.75% of 630198) affected shaders:
Instrs: 2642048 -> 2624362 (-0.67%); split: -0.67%, +0.00%
Cycle count: 79803066 -> 78608872 (-1.50%); split: -1.75%, +0.25%
Max live registers: 421668 -> 421671 (+0.00%)
Tiger Lake and Ice Lake had similar results. (Tiger Lake shown)
Totals:
Instrs: 149995644 -> 149977326 (-0.01%); split: -0.01%, +0.00%
Cycle count: 15567293770 -> 15566524840 (-0.00%); split: -0.02%, +0.01%
Spill count: 61241 -> 61238 (-0.00%)
Fill count: 107304 -> 107301 (-0.00%)
Max live registers: 31993109 -> 31993112 (+0.00%)
Totals from 17813 (2.83% of 629912) affected shaders:
Instrs: 3738236 -> 3719918 (-0.49%); split: -0.49%, +0.00%
Cycle count: 4251157049 -> 4250388119 (-0.02%); split: -0.06%, +0.04%
Spill count: 28268 -> 28265 (-0.01%)
Fill count: 50377 -> 50374 (-0.01%)
Max live registers: 470648 -> 470651 (+0.00%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30251>
This change adds a Vulkan screenshot layer that allows users to take
screenshots from a Vulkan application, but has an emphasis on
performance, decreasing the performance impact on the application
involved. This allows for automated setups to use this layer to take
screenshots for navigating various in-application menus.
This layer works by hooking into various common Vulkan setup functions, until
it enters the vkQueuePresentKHR function, and from there it copies the current
frame's image from the swapchain as an RGB image to host-cached memory, where
we will receive the information as a framebuffer pointer. From there, we copy
the framebuffer contents to a thread that will detach from the main process
so it can write the image to a PNG file without holding back the main thread.
This layer was created from using the existing overlay layer as a template,
then adding portions of LunarG's VulkanTools screenshot layer:
https://github.com/LunarG/VulkanTools/blob/main/layersvt/screenshot.cpp
More specifically, there were usages of functions, along with modifications of
various functions from screenshot.cpp in the VulkanTools project, used in
screenshot.cpp.
There are some sections of the screenshotting functionality that remain
unmodified from the original screenshot.cpp file in VulkanTools, including the
global locking structures and the writeFile() function, which takes care of
obtaining the images from the swapchain. There were various areas in which
modifications were made, including how images are written to a file (using PNG
instead of PPM, introducing threading, added fences/semaphores, etc), along
with many smaller changes.
v2: Fix segfault upon application exit
v3: Fix filename issue with concatenation, along with some leftover
memory handling that wasn't cleaned up.
v4: Fix some error handling and nits
v5: Fix output directory handling
Reviewed-by: Ivan Briano <ivan.briano@intel.com
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30527>
Currently VaSyncBuffer clears the feedback of the buffer's associated encode surface
to avoid a subsequent call to VaSyncSurface for the same encoded frame to retrieve feedback twice.
Add a check to VaSyncSurface to don't perform the feedback retrieval if surf->feedback already cleared.
Otherwise it results in the second call to VaSyncSurface to pass a null feedback
after waiting for the non-null fence.
Fixes: 96fe9fde3f ("frontends/va: Implement sync buffer/surface timeout for encode feedback")
Reviewed-by: David Rosca <david.rosca@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30908>
This instruction is used to implement float type conversion. The source type
is defined via src1 immed (0: f32, 1: f16) and the dest type is defined via
the instruction type.
Blob generates such conv's for piglit's tests/cl/program/execute/mad-mix.cl
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30797>
Don't claim to support extendedDynamicState3SampleLocationsEnable on pre-A650 GPUs,
which can't advertise VK_EXT_sample_locations.
Fixes dEQP-VK.info.device_mandatory_features on A6xx Gen 1 and Gen 2.
Fixes: 84726da2f4 ("tu: Implement extendedDynamicState3SampleLocationsEnable")
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30730>
Two issues:
1. this is a baremetal/fastboot job, not a lava job, so JOB_TIMEOUT does
nothing and TEST_PHASE_TIMEOUT_MINUTES was erroneously removed
instead.
2. the test timeout needs to be smaller than the job timeout, otherwise
it can't do anything. 5min is the margin almost every job uses, so
let's use that.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30928>
It now takes ~45min (likely due to new failures being retried, itself
caused by KHR_shader_subgroup being added), but let's bump the timeout
a bit higher to avoid having to do this again soon.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30928>
(ss) can be used to resolve all tex/sfu/mem WAR hazards. However, when
the reader is a sy-producer, they can also be resolved using (sy). Track
those cases separately and make sure we don't add (ss) when the reader
has already been synced using (sy).
For example, take a sequence like this:
sam rd, rs, ...
(sy)...
(ss)write rs
Before this commit, we would add the (ss) to resolve the WAR hazard
between the consumer (sam) and the writer of rs. However, the consumer
of rs has already been synced using (sy) so has definitely consumed rs.
This commit ensures the unnecessary (ss) for the write is not added
anymore.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30611>
ir3_reg_file_offset should only be called for actual registers, not for
const or immediate values. However, this did happens accidentally for
tracking WAR hazards in ir3_legalize. While that case has been fixed,
better to prevent such cases in the future.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30611>
Sometimes not all of the jobs execute. For instance, Windows build jobs
will not trigger on AMD-only MRs. Use the 'optional' keyword to ignore
jobs which don't exist in our pipeline.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 310e3bb026 ("ci: do not start build-only jobs until the critical build-for-tests jobs are done")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30926>
The storage allocated was always the same for both the ordinary texture
result data as well as the residency info. However, the former can be
float vector, whereas the latter is always int vector.
At least some llvm versions/builds will assert on this mismatch when
storing the data.
While here, also cut unnecessary zero initialization (lp_build_alloca()
already explicitly does this).
Fixes: 6168317b84 (lavapipe: Implement shaderResourceResidency)
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30878>
This change simplifies the code by avoiding special casing, making it easier to add support
for formats like P010 with minimal changes.
Inline it on one place where where the difference for VK_FORMAT_D32_SFLOAT_S8_UINT doesn't matter.
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30899>
