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>
* For now, move the visual mask flags into hgl_context.h
* This removes an un-needed dependency on GLView.h from glvnd
* Eventually, these need converted into normal EGL parameters
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26322>
Anybody will be tempted to factor out the if-else block code since it
looks like duplication but else block actually handles the ycbcr images
where the aspect masks are compatible but don't need to be the same.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26294>
vl_rbsp_fillbits may fill less than 32 bits if it removes emulation
prevention bytes, but will fill at least 16 bits. We need to call it
twice when reading more than 16 bits.
This fixes parsing H264 SPS packed header in va frontend when emulation
prevention bytes are at position where 32 bit values are read.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26276>
Amber
Pierre-Eric Pelloux-Prayer
Marek Olšák
Eric Engestrom
Jesse Natalie
Faith Ekstrand
Juan A. Suarez Romero
Kai Wasserbäch
José Expósito
David Heidelberg
Robert Mader
Kenneth Graunke
José Roberto de Souza
Pavel Ondračka
Samuel Pitoiset
Timothy Arceri
Sil Vilerino
Iván Briano
Alexander von Gluck IV
Sagar Ghuge
David Rosca
Zhang Ning
Daniel Schürmann