Once NIR code is lowered and a few optimization passes have run, there
might be flag register interactions between instructions quite far
away from one another.
In the following case :
f0 = and r0, r1
...
fs_interpolate r2, r3
...
if f0
...
endif
If we lower fs_inteporlate while using the f0 register, we completely
garble the value meant for the if block.
To fix this, emit the predication for fs_interpolate in brw_fs_nir.cpp
when doing the NIR translation to the backend IR. This will guarantee
that the flag register interactions are visible to the optimization
passes, avoiding the problem above.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 68027bd38e ("intel/fs: implement dynamic interpolation mode for dynamic persample shaders")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9757
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26306>
We don't care about patterns like
loop {
...
if (...) {
break;
} else {
...
}
...
}
In that case, we don't need to sync after the if because there's nothing
to re-converge. Every path except one will end up breaking out of it
anyway.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26382>
Fixes dEQP-VK.mesh_shader.ext.smoke.monolithic.mesh_shader_triangle with
nir_opt_combine_stores disabled.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 240e16fc8e ("ac/nir/ngg: Use attribute ring for mesh shader params.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25530>
This fixes hangs with Zink on piglit spec@arb_sparse_buffer tests caused by the double submission.
Fixes: a55d26b566 ("venus: add back sparse binding support")
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26375>
`\$` is interpreted before being passed to `re.search()`, but luckily
for us the escape is also invalid and because of that, python 3.12+
warns us about it.
Use a raw string instead, so that the `\` is passed untouched to
`re.search()`.
Fixes: aa04b47c6e ("intel/perf: add support for GtSlice/GtSliceXDualsubsliceY variables")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26355>
There are no users outside of etnaviv_rs.c.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26096>
Calling etna_rs_gen_clear_surface(..) during surface creation could end
in the following assert:
etna_rs_gen_clear_surface: Assertion `!"" "bpp not supported for clear by RS"'
Lets call etna_rs_gen_clear_surface(..) only when it is needed.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26096>
make it easier to re-use the hidden jobs by other project (e.g. linux)
without enabling the executable jobs.
Inspired on 9442571664 ("ci: separate hiden jobs to -inc.yml files").
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26350>
Upstream removed llvm::createLoopSinkPass() in commit
<b9975cec0e>
and there is no useful alternative except moving to the new pass
manager.
On top of that, the usage of this optimisation pass and
PromoteMemoryToRegisterPass were just useless, according to the
upstream developer of the commit named above. Therefore the easiest
solution is, as him, Marek and Dave suggested, to just remove these two
passes from the pipeline for now.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10192
Reference: https://github.com/llvm/llvm-project/pull/72811
Reference: b9975cec0e
Suggested-by: Dave Airlie <airlied@redhat.com>
Suggested-by: Aiden Grossman <agrossman154@yahoo.com>
Suggested-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26336>
The `zink_internal_create_screen()` function initializes
`screen->drm_fd` to 0, a valid file descriptor value, via `rzalloc`.
If an error is found during initialization, the `zink_destroy_screen()`
function is invoked in the `fail` label and the `screen->drm_fd` is
closed because its value is 0 and `screen->drm_fd != -1` is checked.
Initialize `screen->drm_fd` to -1 to avoid this issue.
Resolves: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10191
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26332>
This is required in order to return the correct value for
`gbm_dri_bo_get_offset()` for e.g. the second plane of a NV12 image.
Use the newly introduced `util_resource` helper and, while on it, also
add support for `gbm_bo_get_plane_count()`.
Cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26283>
This is required in order to return the correct value for
`gbm_dri_bo_get_offset()` for e.g. the second plane of a NV12 image.
Use the newly introduced `util_resource` helper and, while on it, also
add support for `gbm_bo_get_plane_count()`.
Cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26283>
When allocating 2MB chunks of memory, the kernel can use 64K pages if
both the virtual and physical addresses are aligned to 2MB. While we
can't control the physical allocation, we can ensure the virtual address
we use with softpin meets the requirements.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
This should allow us to use 64K pages in more cases, and since the
suballocator is typically used for BOs smaller than 2MB, it probably
isn't going to waste a horrendous amount of memory.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
16K was apparently a little unrealistic - Unigine Superposition has
individual shaders that are larger than 16K. Yikes. Moving to 64K
also puts shaders into the same cache bucket as other allocations.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
On non-LLC systems, most system memory isn't coherent between the CPU
and GPU by default. However, we can enable snooping or 1-way coherency
at a performance cost. In the old days, we maintained one set of cache
buckets and toggled coherency as needed via I915_GEM_SET_CACHING. But
in the modern uAPI (GEM_CREATE_EXT_SET_PAT) we have to select coherency
up front at BO creation time. So this doesn't work out well anymore.
This patch splits system memory into two distinct heaps:
- IRIS_HEAP_SYSTEM_MEMORY_CACHED_COHERENT
- IRIS_HEAP_SYSTEM_MEMORY_UNCACHED
The flags_to_heap() function will select a heap for a given allocation
based on the coherency/scanout requirements, as well as the hardware
configuration (LLC integrated, non-LLC integrated, or discrete card).
Once a heap is selected, it completely determines the cacheability and
coherency settings. A given heap will always have the same mmap mode
and PAT index. This enables us to simplify a lot of code.
Because each heap also has its own bucket cache, we no longer have to
disable bucket caching based on flags, cacheability, coherency, mmap
modes, or so on, as all BOs in each cache have matching settings.
This effectively enables bucket-caching for non-LLC systems.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
We're going to have two system memory heaps and two device local heaps
shortly. Make a helper to avoid having to check for both every time.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Originally we only had a single bucket cache, and it was the main
allocation mechanism. Later on, we added one for device-local memory,
and then a third one for device-local-preferred. Each time, we just
copy and pasted the fields, keeping them all as direct members of the
bufmgr struct. This is getting a bit unwieldy.
This patch introduces an iris_bucket_cache structure to contain the
list of buckets and the number of buckets. It then replaces the three
inline copies with a bufmgr->bucket_cache[heap] array. This lets us
drop a bunch of copy and pasted code in favor of a loop over heaps.
This will also make it easier to add more heaps.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Here renaming the PAT entries to a name that better express each
entry.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Iris doesn't make any call to intel_flush_range*() functions so all BOs
created without BO_ALLOC_COHERENT are not coherent between CPU writes
and GPU reads.
A lot of places don't set BO_ALLOC_COHERENT not even command buffers
have it.
And this incoherency is causing most of tests to fail after
the patch that extracted("iris: Calculate iris_mmap_mode using
intel_device_info_pat_entry when possible") the mmap mode from the PAT
entry.
Before that patch MTL was creating BO with a WB PAT index but then
mmaping as WC.
So to fix this for now making the default PAT entry for Iris a WC one.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Turns out that besides the benefits from nir_move_vec_src_uses_to_dest
itself, it also creates new opportunities for vectorization. Enable it
for vertex shaders, there is a clear instruction win and the only
downside is some increased register presure. However this is mostly
concerning few Unigine Tropics and Sanctiary shaders where we go
11->14 or 10->13 used registers. According to the docs, the increased
register usage would only lower vertex processing concurency if we go
over 15 (R300) or 25 (R500) registers, so we should be safe here.
Fragment shaders are a mixed bag so leave them be for now.
Shader-db RV530
total instructions in shared programs: 129303 -> 128762 (-0.42%)
instructions in affected programs: 13887 -> 13346 (-3.90%)
helped: 99
HURT: 0
total temps in shared programs: 17355 -> 17543 (1.08%)
temps in affected programs: 730 -> 918 (25.75%)
helped: 4
HURT: 66
total cycles in shared programs: 197190 -> 196984 (-0.10%)
cycles in affected programs: 9998 -> 9792 (-2.06%)
helped: 65
HURT: 0
Shader-db RV370:
total instructions in shared programs: 84807 -> 84225 (-0.69%)
instructions in affected programs: 10203 -> 9621 (-5.70%)
helped: 92
HURT: 0
total temps in shared programs: 13036 -> 13231 (1.50%)
temps in affected programs: 787 -> 982 (24.78%)
helped: 4
HURT: 73
total cycles in shared programs: 133178 -> 132946 (-0.17%)
cycles in affected programs: 5911 -> 5679 (-3.92%)
helped: 58
HURT: 0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25417>
