Based on Jianxun's ("iris: don't get format bits in AUX tables").
With gfx12.5+, the compression format is once again coming from the
surface state programming. MTL once again uses an aux-map, but it
ignores the format bits within the the aux-map metadata.
Ref: Bspec 44930: "Compression format from AUX page walk is ignored.
Instead compression format from Surface State is used."
gfx12.5+ also uses tile-4 rather than y-tiling, so if we don't see
y-tiling, we can return 0 from intel_aux_map_format_bits() for the
ignored format bits.
Rework:
* Just return 0 if not using y-tiling as suggested by Nanley.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20322>
Now that devinfo is stored in iris_bufmgr we can nuke this duplicated
flags.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19650>
We can have multiple pipe_screen but only one iris_bufmgr per device.
So better to store intel_device_info into the shared iris_bufmgr and
save some memory.
Also in future patches iris_bufmgr will make more use of
intel_device_info.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19650>
Direct leak of 3912 byte(s) in 2 object(s) allocated from:
#0 0x7fbd4641b0 in __interceptor_malloc (/usr/lib64/libasan.so.6+0xa41b0)
#1 0x7f74413518 in parse_and_validate_cache_item ../src/util/disk_cache_os.c:549
#2 0x7f74414b84 in disk_cache_load_item ../src/util/disk_cache_os.c:599
#3 0x7f74410364 in disk_cache_get ../src/util/disk_cache.c:551
#4 0x7f775695ac in panfrost_disk_cache_retrieve ../src/gallium/drivers/panfrost/pan_disk_cache.c:125
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20336>
GFX11 can have more than 4 SEs. I think it would be better to allocate
an array but that's for later.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20337>
A bit count of es_accepted works for both when ngg is and isn't
dynamically enabled. Unlike the other sequence, this should only be a
single SALU instruction.
fossil-db (gfx1100, nggc):
Totals from 41388 (30.75% of 134574) affected shaders:
Instrs: 25783544 -> 25432959 (-1.36%); split: -1.36%, +0.00%
CodeSize: 127281160 -> 125878820 (-1.10%); split: -1.10%, +0.00%
Latency: 92849566 -> 92723047 (-0.14%); split: -0.14%, +0.00%
InvThroughput: 9542194 -> 9485012 (-0.60%); split: -0.60%, +0.00%
Copies: 2031074 -> 1928796 (-5.04%); split: -5.04%, +0.00%
Branches: 642407 -> 642409 (+0.00%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20321>
This replaces brw_fs_get_dispatch_enables(), which was added in
b9403b1c47 ("intel: factor out dispatch PS enabling logic"), but this
function will not work well for future changes to 3DSTATE_PS.
So, instead, this moves the related code into a "genX" file which can
directly update 3DSTATE_PS for the given platform.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20329>
Some GPUs are able to render more efficiently when all channels of a
color attachment are written, since whole pixels are being overwritten,
rather than hitting a read-modify-write cycle where newly written data
has to be combined with existing unmodified image data.
When faking GL_RGB as RGBA (in case RGB/RGBX isn't color renderable),
we introduce an extra channel that doesn't exist from the application
point of view. With such a format, a color mask of 0x7 (RGB) would mean
to write all channels. But because we've added an alpha channel behind
their back, this becomes a partial write. We are free to write whatever
garbage we want to the alpha channel, however. So we can enable alpha
writes, making this a more efficient full pixel write again.
This is done unconditionally as it's expected to address a problem
common to many drivers and isn't expected to be harmful, even on GPUs
where it may not help much.
Improves WebGL Aquarium performance on Alderlake GT1 by around 2.4x, in
the Chromium, using Wayland (the --enable-features=UseOzonePlatform and
--ozone-platform=wayland flags).
v2: Don't require PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND (Marek)
v3: Fix independent blending enables (Emma) - now set when needed,
skipped when not needed, and PIPE_CAP_INDEP_BLEND_ENABLE is no
longer a requirement. We just optimize where we can.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7864
Reviewed-by: Matt Turner <mattst88@gmail.com> [v1]
Reviewed-by: Marek Olšák <marek.olsak@amd.com> [v2]
Reviewed-by: Emma Anholt <emma@anholt.net> [v3]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20290>
While all Panfrost-supported Mali GPUs support all the compressed texture
formats architecturally, the system integrator decides which formats will
actually be wired up in the production system-on-chip. In the past there may
have been legal considerations, I'm neither a lawyer nor a system integrator so
couldn't say.
It's useful for users to know which compressed texture formats are supported by
their hardware, to understand its performance characteristics (and perhaps to
buy systems that support their needs, especially if they need BCn formats which
are omitted in many Mali implementations).
To help with that, this commit adds a small standalone tool that prints which
formats are supported. It is tested so far on Mali-T860 and Mali-G57.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Tested-by: Chris Healy <healych@amazon.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20086>
This removes the ALU-only restriction on the "weak" GVN introduced by
the previous commit. This makes it slightly more aggressive, allowing
it to coalesce things like UBO loads (still within sister then/else
blocks). This also can have surprisingly large cascading effects.
I was concerned that this might increase register pressure, but
shader-db and fossil-db show effectively no change in spills/fills,
so it seems to be fine.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19823>
Full global value numbering (GVN) can be pretty aggressive, moving
values far away from their original locations, even out of loops,
and can extend their live ranges a lot. So we've left it disabled.
This patch introduces a weaker form of GVN: we only allow coalescing
identical values when they appear on either side of the same if/else
construct. For now, we also only allow ALU instructions.
This allows nir_opt_gcm to clean up identical instructions appearing
on both sides of if/then/else control flow. But it avoids aggressively
combining every other occurrence of a value in the program.
This can still have surprisingly large cascading effects, as simple
constructs are cleaned up, leading to more opportunities to do the
same clean up, up a chain of nested ifs. It also enables greater use
of the select peephole as ifs are cleaned up.
shader-db and fossil-db results show a reduction in spills/fills on
Icelake, so it doesn't seem to be hurting register pressure.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19823>
This is another field that, after the recent commits, became unused.
It's either zero-initialized (by the memset) or copy-initialized
(which means it's also zero). And it never even gets used anywhere
anyway, so even if the value was non-zero it wouldn't matter.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20309>
As a consequence of the last two commits, reloc_bos is always NULL and
never used anywhere, so remove it.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20309>
The last commit made it clear that anv_reloc_list_grow() only ever
gets called with zero as num_additional_relocs, which means it will
always immediately return VK_SUCCESS without doing anything. That
means we can remove it.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20309>
There are only a few places in the code where num_relocs gets set:
- During anv_reloc_list_init() where it gets memset() to 0.
- At anv_reloc_list_init_clone() where it gets set with the value of
another anv_reloc_list->num_relocs.
- During anv_reloc_list_clear(), where it gets set to 0.
- During anv_reloc_list_append(), where it gets added with the value
of another anv_reloc_list->num_relocs.
As you can see, either we explicitly set the value to 0 or we copy the
value that's present in another anv_reloc_list, which should be 0. The
one place where we used to increment num_relocs was in
anv_reloc_list_add(), but that was deleted by:
7b7381e8d7 ("anv: Delete anv_reloc_list_add()")
So in this commit we delete the num_relocs field from struct
anv_reloc_list and we also delete some lines where, if the value is 0,
nothing will happen.
There's more we could be deleting here, but I wanted this commit to be
minimal so it's very clear that num_relocs can't be non-zero. We were
having some speculation that anv_reloc_list may still be important for
actually adding BOs to the batch and building the validation list, so
let's go slowly with the removal to make everything more easily
reviewable.
The one possibility I could be missing here is another situation like
the memset() we have at anv_reloc_list_init() or some other crazy
indirect overwrite, but as far as I have checked, that is not the
case.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20309>
Now that we removed relocations, this is not being used anywhere.
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20309>
The hardcoded is either replaced with new interfaces or relocated
to C file if it is private.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20259>
gitlab-runner reuses containers, and since we don't pull git, the working
directory doesn't get cleaned automatically. You don't want to have stale
files from previous builds, particularly if someone's testing changes of
build options that might disable a driver.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20302>
The lock and condition variable isn't just for present_id anymore,
it's also for normal forward progress.
Adds more detailed comments what the variables are supposed to
accomplish.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19990>
With the introduction of locks around the XCB polling mechanism,
a possible deadlock was introduced.
If all 5 images were rapidly acquired and presented before the
FIFO thread had the chance to submit a present,
we would deadlock.
Before the lock however, it was still buggy since the two threads would
race to poll events and update internal state.
The fix is to just ensure that there are pending presentation requests
in flight, so that forward progress is guaranteed before we take the
poll lock.
Also, use a timedlock for acquire next image.
Similar as WaitForPresentKHR.
Also need to make the busy flag atomic to actually allow acquire thread
and present threads to access the busy flag.
Take advantage of busy flag being atomic so that we can gracefully handle
timeout == 0 scenarios where there actually are images available.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 8fc7927787 ("wsi/x11: Implement VK_KHR_present_wait on X11.)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19990>
