This moves some ops down to when they're needed, generally reducing the
number of temps in use. It's not always a win -- sometimes you can end up
moving a generator of a component used by a nir_op_vec down, which means
that op's sources stay live while the vec (whose register likely gets
coalesced with the ops creating it) is also live. But it's generally
good.
softpipe results:
temps in affected programs: 18115 -> 18026 (-0.49%)
imm in affected programs: 19 -> 22 (15.79%)
r300 results:
instructions in affected programs: 174 -> 178 (2.30%)
vinst in affected programs: 156 -> 160 (2.56%)
sinst in affected programs: 54 -> 50 (-7.41%)
temps in affected programs: 2634 -> 2169 (-17.65%)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14096>
This brings us into parity on state tracker paths with most other
supported drivers, and a lot of additional optimization on our shaders.
Results on a subset of shader-db that doesn't crash:
instructions in affected programs: 59502 -> 47991 (-19.35%)
vinst in affected programs: 17633 -> 15197 (-13.82%)
sinst in affected programs: 9296 -> 7319 (-21.27%)
flowcontrol in affected programs: 627 -> 310 (-50.56%)
presub in affected programs: 4220 -> 1554 (-63.18%)
temps in affected programs: 5775 -> 8570 (48.40%)
lits in affected programs: 215 -> 37 (-82.79%)
The temps (register usage) increase is unfortunate, but it seems that
instruction counts tend to be our limit before reg counts are.
Fixes: #3354
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14096>
According to the Vulkan spec chapter 9.25 Helper Invocations,
quad group operations have to be executed by helper invocations.
This commit cleans up the code for quad group instructions by
unifying the code path of quad broadcast with the others, and then
calling emit_wqm just once at the end.
Fixes: 93c8ebfa78
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5570
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13929>
Newer version of XServer supporting GLX_DRAWABLE_TYPE query also
support query with raw X11 window ID besides GLXWindow ID. So we
should not limit the suppported type to GLXPbuffer when query
success.
Otherwise can't start GLX application on newer XServer with:
libGL error: GLX drawable type is not supported
libGL error: GLX drawable type is not supported
X Error of failed request: GLXBadContext
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 5 (X_GLXMakeCurrent)
Serial number of failed request: 35
Current serial number in output stream: 35
Fixes: 6625c960c5 ("glx: check drawable type before create drawble")
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14120>
Previously a predicated BREAK that appeared immediately before the WHILE
would get merged into the WHILE. This doesn't work if other flow
control (e.g., a CONT) can transfer directly to the WHILE.
On Intel platforms, this fixes the CTS test
dEQP-VK.graphicsfuzz.stable-binarysearch-tree-nested-if-and-conditional.
No shader-db changes on any Intel platform.
When this commit was first created (over a month before it is going to
land), there were some regressions that were prevented by other commits
in MR !13095. That does not appear to be the case now, so I don't know
what changed. Basically, the treatment of discard as a combination of
demote and terminate causes additional continues in some loops, and
those continues trigger this bug. The other commits from that MR
prevent those continues from being generated in the first place.
All Intel platforms had simlar fossil-db results. (Ice Lake shown)
Instructions in all programs: 144419989 -> 144419995 (+0.0%)
SENDs in all programs: 6947332 -> 6947332 (+0.0%)
Loops in all programs: 38277 -> 38277 (+0.0%)
Spills in all programs: 204075 -> 204075 (+0.0%)
Fills in all programs: 319480 -> 319480 (+0.0%)
A few shaders in Doom 2016 were hurt by one instruction each. It seems
likely that these shaders would have experienced at least some
mis-rendering.
Closes: #4213
Fixes: d13bcdb3a9 ("i965/fs: Extend predicated break pass to predicate WHILE.")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14128>
When mesa3d is built without VK_USE_PLATFORM_DISPLAY_KHR definition,
dEQP test fails:
dEQP : Test case 'dEQP-VK.info.instance_extensions'..
dEQP : Fail (Extension VK_KHR_get_display_properties2 is missing
dependency: VK_KHR_display)
dEQP : DONE!
Enable KHR_get_display_properties2 only if VK_USE_PLATFORM_DISPLAY_KHR
is enabled.
Fixes: f884c2e3be ("v3dv: implement VK_KHR_get_display_properties2")
Signed-off-by: Roman Stratiienko <roman.o.stratiienko@globallogic.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14047>
Draw is only called in the feedback paths now, and the only thing
it is set to is the st feedback draw path.
So just always have the fallback call the draw feedback path and
get rid of the draw entry.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14100>