Since commit d413fd0219 ("gallivm: Always take the per-pixel LOD path
for cubemaps.") the special cube rho code was not used anymore.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18892>
this massively reduces the number of pipelines required
also temporarily disable GPL until a few more patches land since something's
weird and broken
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18890>
This was missed. I guess CI doesn't have a recent enough LLVM for these
tests.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17710>
Add GFX11 support and use wait_imm::unset_counter. Looping in the waitcnt
pass was probably broken on GFX11 because of this.
fossil-db (gfx1100):
Totals from 899 (0.56% of 161689) affected shaders:
Instrs: 1319368 -> 1319179 (-0.01%)
CodeSize: 7124640 -> 7123884 (-0.01%)
Latency: 26554304 -> 26404606 (-0.56%)
InvThroughput: 9032485 -> 8978773 (-0.59%); split: -0.59%, +0.00%
No navi10 fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17710>
According to an LLVM comment, these are swapped in GFX11.
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17710>
The info that a loop contains fp64 ops is lost after full
software lowering.
Therefore, specifically unroll these loops in zink instead of
in vulkan, where the blown up body is no longer unrolled.
This helps a lot in KHR-Single-GL46.arrays_of_arrays_gl.SubroutineFunctionCalls2.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18863>
Lowered fp64 ops can blow up the loop bodies while still being
suitable for unrolling.
Allow for using different parameters to unroll loops with
soft fp64.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18863>
There are vulkan drivers that support Int64 but not Float64.
Optimise the 64bit lowering by converting doubles to uint64,
but keep matrix lowerig to float as glsl int64 matrices do
not exist.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18863>
All the warnings are now fixed.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18613>
This fixes a warning with stringop-truncation:
```
error: 'strncpy' output may be truncated copying 127 bytes from a string of length 255 [-Werror=stringop-truncation]
1443 | strncpy(graph->name, s, sizeof(graph->name)-1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18613>
It doesn't make sense for a "s_waitcnt vmcnt(0)" to affect a store or DS
instruction.
LLVM checks for "s_waitcnt vmcnt(0) lgkmcnt(0) expcnt(0)" but ignores
s_waitcnt_vscnt (which I assume is a bug).
No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: bcf94bb933 ("aco: properly recognize that s_waitcnt mitigates VMEMtoScalarWriteHazard")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18270>
In case if the surface->resolve_type is not PVR_RESOLVE_TYPE_PBE
then we do not setup pbe_cs_words in which case we might end up
using garbage values.
Fixes: CID 1515466.
Signed-off-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18866>
Logically the hw_render would never be NULL so the if block is
never used and can be removed.
Fixes: CID1503270.
Signed-off-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18866>
Framebuffer can not be NULL in pvr_CmdBeginRenderPass2.
Fixes: CID 1503259.
Signed-off-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18866>
This commit converts attachment indexes used in renderpass to unsigned
and uses VK_ATTACHMENT_UNUSED for unused attachments instead of -1.
Also fixes some signed to unsigned comparisons.
Fixed: CID 1515587, 1515590, 1515597, 1515604.
Signed-off-by: Rajnesh Kanwal <rajnesh.kanwal@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18866>
This seems to resolve the memory explosion without hurting performance.
This workaround is only applied for native Vulkan.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18884>
