For VK_KHR_fragment_shader_barycentric, AMD needs to know the primitive
topology in the fragment shader but with fast-link GPL this is unknown
at compile time and it needs to be passed dynamically.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16742>
For fast-linking with GPL, we might not know the pre-rasterization
stages at compile time (when only the FS is compiled) and we will need
to load the rasterization primitive through an user SGPR.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16742>
This is no longer used.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21624>
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21624>
This is needed to create barriers which ensure stores finish before
position/primitive exports.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21624>
v_add can be dual issued on gfx11, v_med3 cannot.
Don't use v_add directly to still optimize omod(fsat(x)).
Foz-DB GFX1100:
Totals from 32702 (24.24% of 134913) affected shaders:
Latency: 475008203 -> 474928037 (-0.02%); split: -0.02%, +0.00%
InvThroughput: 59226198 -> 59140787 (-0.14%); split: -0.14%, +0.00%
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21402>
Printing the final shaders in etna_link_shaders(..) can be quite noisy and
does not work when using shader-db. Lets make it possible to stare at the
generaded shader code when using shader-db by moving the etna_dump_shader(..)
call into create_variant(..).
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23396>
code_size is overall size in uint32 words of the whole shader. As
Vivante GPUs have a fixed size ISA we simply need to divide code_size
by 4 to get the number if ISA instructions.
shader-db shows the correct numbers now.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23396>
Contrary to how we implemented barriers the MEMBAR instruction actually
does not allow us to specify which memory to synchronize. We can only
specify the scope.
No regressions on TU102.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: M Henning <drawoc@darkrefraction.com>
Signed-off-by: Karol Herbst <git@karolherbst.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23208>
This only used by vulkan drivers and depends on vulkan util, so do the move to decouple
nir from vulkan utils
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23444>
I tried emitting less here but I'm just gonna hit it with the big
seq_cst hammer.
Fixes:
dEQP-VK.memory_model.message_passing.*
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23453>
Instead of incrementing the seqno, just directly invalidate any existing
tex cache entries when we update a sampler view.
No reason not to just directly clear stale entries, and avoiding to re-
assign the seqno will simplify the next patch.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23470>
The internal layout used with compression partially depends on the pixel format.
Some limited reinterpretation is definitely allowed (linear vs sRGB views of the
same physical format are documented by Apple as allowed). Some reinterpretations
are definitely forbidden (R8G8B8A8 vs R32, I think). At some point we'll need to
work out the exact rule. I suspect the answer is that "you can reinterpret iff
the Channels field matches". Meaning that R8G8B8A8_UNORM and B8G8R8A8_SINT would
be compatible, but not R16G16_UNORM. But I haven't tested that.
Fixes all fails in:
dEQP-GLES31.functional.image_load_store.*.format_reinterpret.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23480>
