This is to ensure the kernel operations and the later ring operations
are in the right order.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10390>
VkImportMemoryFdInfoKHR takes fd ownership on a successful import.
Internally, vn_renderer_bo_create_dmabuf doesn't rely on the fd to
extend the life cycle of the bo or the host resource, and it won't
close the fd. Thus, we shall close the fd when the import succeeds.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10390>
This commits fixes a regression caused by commit
616394cf31.
Fixes dEQP-GLES31.functional.compute.shared_var.atomic.min.*,
dEQP-GLES31.functional.ssbo.atomic.min.*,
dEQP-GLES31.functional.compute.shared_var.atomic.max.* and
dEQP-GLES31.functional.ssbo.atomic.max.*.
Midgard's non-image and non-varying store operations have a unique
behavior for the load/store writemask, with each bit being responsible
for 1/4th of the size of the total write operation. This means that we
have to pack the writemask differently since we stopped using st_u128
for everything.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10067>
To vectorize to vec8/16 or vec4 (without vec3), we can't incrementally add
components to a load/store. This patch loops vectorization so that two new
vec2/4/8 operations can be combined into a larger operation.
fossil-db (GFX10.3):
Totals from 22 (0.02% of 139391) affected shaders:
SpillVGPRs: 1749 -> 1771 (+1.26%)
CodeSize: 901212 -> 892532 (-0.96%); split: -1.19%, +0.22%
Scratch: 178176 -> 184320 (+3.45%)
Instrs: 159358 -> 158027 (-0.84%); split: -0.99%, +0.16%
Cycles: 37046772 -> 36738544 (-0.83%); split: -1.00%, +0.17%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10384>
The major thing that the codegen had was support for expanding integers
from byte-per-channel to the target format's channel size. However, the
format_utils.c caller never did that for integers, and swrast doesn't have
support for integers, so that appears to be dead code. With this done,
format_pack.py goes away entirely.
I slightly changed the prototype of _mesa_pack_ubyte_rgba_row() to match
up with the new function, which involved (mostly) dropping some manual
casts from the callers to make their data match the old prototype.
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>
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>
