Only swrast uses them, and this makes it clearer why we only need partial
format support for them, avoids linker work deleting them for gallium
drivers, and means they will automatically go away when we get to finally
delete swrast.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10336>
It was only used here, and this made it clear (see
draw_depth_stencil_pixels()) that the z32f_s8 case was unused and could be
dropped. Also, it means this code will nicely go away when swrast is
deleted.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
X
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10336>
util_format_pack_s_8uint() has the same behavior of replacing the s
values but supports more formats.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10336>
channel datatypes in Mesa are the host's endianness. For example,
PIPE_FORMAT_R32_UINT doesn't do a bswap in and out in u_format_table.c's
pack/unpack functions. So, z32_unorm shouldn't be byte swapping either,
and neither should z24s8 which is also a packed format, and once you've
got those it becomes clear that all of the swaps in this file were
mistaken.
Things would mostly work out because it's unusual to read/write Z/S data
through the GL API, and even for drivers like softpipe as long as the pack
and unpack both swap it could work anyway. However, the bug would be
visible in glReadPixels() with the matching datatype which would hit the
memcpy fastpath without doing another swap.
Caught by a mesa/main unit test on transitioning to using these
pack/unpack functions.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10336>
EARLY_ZS_ALWAYS was introduced in Bifrost v7. Use ALWAYS (or INTERSECT
depending on the situation) on v6.
Fixes: 8ba2f9f698 ("panfrost: Create a blitter library to replace the existing preload helpers")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Icecream95 <ixn@keemail.me>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10250>
generally speaking, if I'm tracing an app, I want to see what's happening to
my driver, not what's happening to tc, as tc does rewriting of command streams
which can affect the operation of the driver
use GALLIUM_TRACE_TC for previous behavior
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10362>
we should probably trigger this any time a flush occurs just to avoid
doing too much (unexpected) cmdstream rewriting
both calls must be kept, however, as the one in the base flush hook will change
the behavior of flushing if no other work is queued
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
there's no need to have an intermediate pointer here since that only
complicates keeping scanout synchronized
this also eliminates the pointer on the context since it isn't used anymore
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
having a resource pointer on batch states is now a requirement for
keeping scanout objects in sync
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
this minimizes overhead of maintaining scanout objects
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
this is called from the non-deferred flush path, which means it should always
be triggering work, which means it will always result in a queue submission
instead of relying on the pipe_context::flush hook to be triggered, which is
not a guarantee, do scanout sync during queue submission to ensure that scanout
objects are always in sync
Fixes: 104603fa76 ("zink: create separate linear tiling image for scanout")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10358>
The EOS (End Of Shader) is set if the first successor is NULL, but the
second successor should be checked too.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10369>
Use panfrost_batch_reserve_tls() to reserve the TSD.
Cc: mesa-stable
Fixes: ff3eada7eb ("panfrost: Use the generic preload and FB helpers in the gallium driver")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10369>
These are used to effectively disable dithering on the tilebuffer, but
we already disable dithering on a per-primitive basis anyway, so don't
bother.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10188>
Avoids a util_format_description call in a hot path, and drops some
indirection everywhere.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10188>
Avoids the need to go between linear and sRGB pipe formats in the hot
path. We're already reserving the space, may as well use it.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10188>
Avoids a layer of indirection in a hot path, at the expense of a greater
memory foot print. (Is this a win?)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10188>
On a6xx/a5xx there is such dependency between branchstack bitfield
and the amount of nested ifs, which could be seen with blob:
IFs BRANCHSTACK
0 0
1 1
2 2
3 2
4 3
5 3
6 4
...
59 30
60 31
61 31
62 32
63 32
64 32
Remove open-coded branchstack for a5xx compute along the way.
Fixes tests:
dEQP-VK.spirv_assembly.instruction.compute.float16.opvectorshuffle.344
dEQP-VK.spirv_assembly.instruction.graphics.float16.opvectorshuffle.344_vert
dEQP-VK.spirv_assembly.instruction.graphics.float16.opvectorshuffle.444_geom
dEQP-VK.spirv_assembly.instruction.graphics.float16.opvectorshuffle.244_tessc
dEQP-VK.spirv_assembly.instruction.graphics.float16.opvectorshuffle.344_frag
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9859>
We can't support more than compiler->branchstack_size diverging threads
in a wave. Thus, doubling the threadsize is only possible if we don't
exceed the branchstack size limit.
As of blob version 512.490.0 - it doesn't have this heuristics.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9859>
It's impossible to see the names of instructions if the terminal's
color scheme uses black as foreground. Just set it to white - it
will look good on any color scheme.
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10341>
This is used when printing the program and to avoid updating register
demand during post-RA liveness analysis.
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/10315>
p_extract_vector copy-propagation can create byte sels for v2b operands.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10315>
It isn't intended to be accurate after RA, so num_waves can become zero,
breaking the sgpr_limit calculation.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10315>
DCC decompress/FMASK expand are supported on compute queues. Since
the driver doesn't perform fast clears with concurrent images, we
don't need to perform a FCE on compute (we can't anyways).
This fixes a performance regression with Control and
VKD3D_CONFIG=multi_queue.
One more optimization (as discussed with Bas) is to implement FCE
on compute to allow fast clears.
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/10323>
