If there is a single use of fmul, and that single use is fadd, it makes
sense to fuse ffma, as we already do. However, if there are multiple
uses, fusing may impede code gen. Consider the source fragment:
a = fmul(x, y)
b = fadd(a, z)
c = fmin(a, t)
d = fmax(b, c)
The fmul has two uses. The current ffma fusing is greedy and will
produce the following "optimized" code.
a = fmul(x, y)
b = ffma(x, y, z)
c = fmin(a, t)
d = fmax(b, c)
Actually, this code is worse! Instead of 1 fmul + 1 fadd, we now have 1
fmul + 1 ffma. In effect, two multiplies (and a fused add) instead of
one multiply and an add. Depending on the ISA, that could impede
scheduling or increase code size. It can also increase register
pressure, extending the live range.
It's tempting to gate on is_used_once, but that would hurt in cases
where we really do fuse everything, e.g.:
a = fmul(x, y)
b = fadd(a, z)
c = fadd(a, t)
For ISAs that fuse ffma, we expect that 2 ffma is faster than 1 fmul + 2
fadd. So what we really want is to fuse ffma iff the fmul will get
deleted. That occurs iff all uses of the fmul are fadd and will
themselves get fused to ffma, leaving fmul to get dead code eliminated.
That's easy to implement with a new NIR search helper, checking that all
uses are fadd.
shader-db results on Mali-G57 [open shader-db + subset of closed]:
total instructions in shared programs: 179491 -> 178991 (-0.28%)
instructions in affected programs: 36862 -> 36362 (-1.36%)
helped: 190
HURT: 27
total cycles in shared programs: 10573.20 -> 10571.75 (-0.01%)
cycles in affected programs: 72.02 -> 70.56 (-2.02%)
helped: 28
HURT: 1
total fma in shared programs: 1590.47 -> 1582.61 (-0.49%)
fma in affected programs: 319.95 -> 312.09 (-2.46%)
helped: 194
HURT: 1
total cvt in shared programs: 812.98 -> 813.03 (<.01%)
cvt in affected programs: 118.53 -> 118.58 (0.04%)
helped: 65
HURT: 81
total quadwords in shared programs: 98968 -> 98840 (-0.13%)
quadwords in affected programs: 2960 -> 2832 (-4.32%)
helped: 20
HURT: 4
total threads in shared programs: 4693 -> 4697 (0.09%)
threads in affected programs: 4 -> 8 (100.00%)
helped: 4
HURT: 0
v2: Update trace checksums for virgl due to numerical differences.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18814>
When appending the content of a util_dynarray to another util_dynarray, we
need to copy the content to the *end* of the util_dynarray, not the
beginning.
As we've already resized the dynarray, We also shouldn't add to the size
once more at the end, otherwise we'll end up with garbage.
Fixes: 43dcdf3365 ("zink: rework/improve descriptor pool overflow handling on batch reset")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7485
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19068>
Zink on Anv running Gfxbench gl_driver2 is significantly slower than
Iris.
The reason is simple, whereas Iris implements uniform updates using
push constants and only has to emit 3DSTATE_CONSTANT_* packets, Zink
uses push descriptors with a uniform buffer, which on our
implementation use both push constants & binding tables.
Anv ends up doing the following for each uniform update :
- allocate 2 surface states :
- one for the uniform buffer as the offset specify by zink
- one for the descriptor set buffer
- pack the 2 RENDER_SURFACE_STATE
- re-emit binding tables
- re-emit push constants
Of all of those operations, only the last one ends up being useful in
this benchmark because all the uniforms have been promoted to push
constants.
This change defers the 3 first operations at draw time and executes
them only if the pipeline needs them.
Vkoverhead before / after :
descriptor_template_1ubo_push: 40670 / 85786
descriptor_template_12ubo_push: 4050 / 13820
descriptor_template_1combined_sampler_push, 34410 / 34043
descriptor_template_16combined_sampler_push, 2746 / 2711
descriptor_template_1sampled_image_push, 34765 / 34089
descriptor_template_16sampled_image_push, 2794 / 2649
descriptor_template_1texelbuffer_push, 108537 / 111342
descriptor_template_16texelbuffer_push, 20619 / 20166
descriptor_template_1ssbo_push, 41506 / 85976
descriptor_template_8ssbo_push, 6036 / 18703
descriptor_template_1image_push, 88932 / 89610
descriptor_template_16image_push, 20937 / 20959
descriptor_template_1imagebuffer_push, 108407 / 113240
descriptor_template_16imagebuffer_push, 32661 / 34651
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19050>
VUID-VkPipelineLayoutCreateInfo-pSetLayouts-00293
pSetLayouts must not contain more than one descriptor set layout
that was created with
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR set
There is only one push descriptor set with all the descriptor sets, so
no need to have an array.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19050>
Otherwise users of `idep_vulkan_wsi` won't pull in the udev dependency,
which will cause the linker to fail later on in compiling.
The user of this dependency is lavapipe which would fail to link if this
isn't provided.
Fixes: 4885e63a6d (vulkan/wsi: implement missing wsi_register_device_event)
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19037>
There was a security problem with some `gitlab_gql.py` scenarios because
of `\r` and `\n` in the token file, which interrupted the requests for
Gitlab endpoints.
Stripping the token file after reading the file content solves the
problem.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18066>
...Rather than reserving the union of the registers live-out of the
predecessors. This avoids reserving registers that are killed along a
control flow edge (where the predecessor has another successor that does
use the register).
glmark2 subset of shaderdb:
total instructions in shared programs: 6442 -> 6440 (-0.03%)
instructions in affected programs: 42 -> 40 (-4.76%)
helped: 1
HURT: 0
total bytes in shared programs: 42186 -> 42174 (-0.03%)
bytes in affected programs: 270 -> 258 (-4.44%)
helped: 1
HURT: 0
total halfregs in shared programs: 1769 -> 1757 (-0.68%)
halfregs in affected programs: 75 -> 63 (-16.00%)
helped: 3
HURT: 0
helped stats (abs) min: 4.0 max: 4.0 x̄: 4.00 x̃: 4
helped stats (rel) min: 16.00% max: 16.00% x̄: 16.00% x̃: 16.00%
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18804>
This means we don't reserve the registers, which improves RA
considerably. Using a special preload psuedo-op instead of a regular
move allows us to constrain semantics and gaurantee coalescing.
shader-db on glmark2 subset:
total instructions in shared programs: 6448 -> 6442 (-0.09%)
instructions in affected programs: 230 -> 224 (-2.61%)
helped: 4
HURT: 0
total bytes in shared programs: 42232 -> 42196 (-0.09%)
bytes in affected programs: 1530 -> 1494 (-2.35%)
helped: 4
HURT: 0
total halfregs in shared programs: 2291 -> 1926 (-15.93%)
halfregs in affected programs: 2185 -> 1820 (-16.70%)
helped: 75
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18804>
José Roberto de Souza